EveBox on Ubuntu 24.04 on Azure User Guide

Overview

This image runs EveBox 0.26.0, a web based event viewer and alert triage console for Suricata, together with Suricata 7.0.3, the open source intrusion detection engine that produces the alerts, on Ubuntu 24.04 LTS.

EveBox on its own is a viewer over an event stream it does not produce, so this image ships the complete appliance. Suricata captures traffic on the instance's primary network interface, matches it against the Emerging Threats open ruleset, and writes alerts along with flow, DNS, TLS and HTTP metadata to /var/log/suricata/eve.json. EveBox indexes that stream into a local SQLite datastore, so there is no Elasticsearch cluster to run, and presents it as a searchable analyst inbox in the browser.

The cloudimg image is secure by default. EveBox runs bound only to the loopback interface and is fronted by nginx on port 80 using HTTP Basic authentication. The password is a unique value generated on first boot for each instance and written to a root only file. No credential is baked into the image, and no two deployments share one. Because EveBox is bound to loopback, that authentication cannot be bypassed by reaching the application port directly.

What is included:

• EveBox 0.26.0 installed from the official upstream release, running as a dedicated non root evebox service bound to 127.0.0.1:5636
• Suricata 7.0.3 configured for af-packet capture on the instance's primary interface, with the Emerging Threats open ruleset loaded at build time
• A self contained SQLite datastore at /var/lib/evebox with no external search cluster required
• nginx on port 80 reverse proxying the console and its JSON API with HTTP Basic authentication, plus an unauthenticated /healthz endpoint for Azure Load Balancer probes
• A one shot evebox-firstboot.service that pins the capture interface to this instance's NIC, generates a per instance password on first boot and writes it to /root/evebox-info.txt (mode 0600)
• A shipped pipeline self test signature so you can prove the whole capture, index and display chain with one command
• A fully patched Ubuntu 24.04 LTS base with unattended security upgrades enabled
• 24/7 cloudimg support

EveBox is published by the EveBox project under the MIT licence, and Suricata is published by the Open Information Security Foundation under the GPL 2.0 licence. This image is packaged by cloudimg and is not affiliated with or endorsed by the EveBox or Suricata projects.

Prerequisites

An active Azure subscription, an SSH key pair, and a VNet plus subnet in the target region. Standard_B2s (2 vCPU / 4 GiB RAM) is a sensible starting size; increase CPU and memory for busier links or a larger ruleset. NSG inbound: allow 22/tcp from your management network and 80/tcp for the console. EveBox serves plain HTTP on port 80; for production or shared access, terminate TLS in front of it with your own domain using a reverse proxy or Azure Application Gateway.

A note on what this sensor sees: Suricata inspects traffic arriving at this VM's own network interface. That makes it an excellent host based sensor and a working monitoring point for anything routed through it. To inspect traffic for other machines, route or mirror that traffic through this instance, for example by making it a NAT or gateway hop.

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for EveBox by cloudimg, and select Create. On Basics pick your subscription, resource group, region and size; under Administrator account choose SSH public key and paste your key; under Inbound port rules allow SSH (22) and HTTP (80). Then Review + create then Create.

Step 2 - Deploy from the Azure CLI

az vm create \
  --resource-group <your-rg> \
  --name evebox \
  --image <marketplace-image-urn> \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard

az vm open-port --resource-group <your-rg> --name evebox --port 80 --priority 1010

Step 3 - Connect to your VM

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services are running

The appliance is three cooperating units: suricata.service captures and detects, evebox.service indexes and serves the console on the loopback interface, and nginx.service fronts it on port 80. A one shot evebox-firstboot.service runs once on first boot to pin the capture interface and generate the per instance password. Confirm all four are active, and that nginx is listening on port 80 while EveBox stays private on 127.0.0.1:5636:

systemctl is-active suricata evebox nginx evebox-firstboot

ss -tlnp | grep -E ':80 |:5636 '

The second command is the security check that matters: EveBox must appear only on 127.0.0.1:5636. If it were bound to 0.0.0.0, the console would be reachable without passing through nginx authentication.

Step 5 - Retrieve your per instance credentials

The first boot service writes the console URL, username and generated password to /root/evebox-info.txt, readable only by root:

cat /root/evebox-info.txt

The file also records where Suricata is writing events, how to refresh the ruleset, and how to rotate the password. Copy the password somewhere safe, such as a password manager. To change it later:

sudo htpasswd -B /etc/nginx/evebox.htpasswd evebox

Step 6 - Confirm the console is secure by default

Without credentials, nginx refuses the request. With the per instance password, the same endpoint returns the EveBox version:

curl -s -o /dev/null -w 'HTTP %{http_code} (authentication required)\n' http://127.0.0.1/api/version

curl -s -u evebox:<evebox-password> http://127.0.0.1/api/version | python3 -m json.tool

The first call returns HTTP 401. The unauthenticated /healthz endpoint stays open so an Azure Load Balancer can probe the instance without credentials:

curl -sI http://127.0.0.1/healthz | head -1

Step 7 - Prove the detection pipeline end to end

The image ships a narrow self test signature, sid 9000001, that matches only ICMP carrying the ASCII marker cloudimg. It fires only when you send the probe deliberately, so it adds no noise to ordinary traffic, and it proves every link in the chain at once: the wire, Suricata, eve.json, the SQLite index, and the authenticated web API.

First confirm the Emerging Threats ruleset is loaded:

grep -cE '^[[:space:]]*(alert|drop|reject|pass)[[:space:]]' /var/lib/suricata/rules/suricata.rules

Now send the probe at your default gateway and confirm Suricata wrote the alert:

GW=$(ip -o -4 route show to default | awk '{print $3}' | head -1); ping -c 3 -W 1 -p 636c6f7564696d67 "$GW" >/dev/null 2>&1; sleep 5; grep -o '"signature":"cloudimg EveBox pipeline self-test"' /var/log/suricata/eve.json | head -1

The gateway does not need to reply; the probe only has to leave the monitored interface. Finally, confirm EveBox has indexed it and will serve it through the authenticated API:

curl -s -u evebox:<evebox-password> http://127.0.0.1/api/alerts | python3 -c "import sys,json;d=json.load(sys.stdin);print(json.dumps([e['_source']['alert']['signature'] for e in d.get('events',[])], indent=2))"

You should see cloudimg EveBox pipeline self-test in the list, alongside any real signatures Suricata has already matched against live traffic.

Step 8 - Sign in to the EveBox console

Open http://<vm-public-ip>/ in a browser. Sign in with the username evebox and the password from Step 5. EveBox opens on the Inbox, its main triage view: every alert Suricata has raised, newest first, grouped by signature with a count, the source and destination addresses, and the time.

From here you can Archive an alert you have dealt with, Escalate one that needs follow up (escalated alerts get their own view), or use the search box to filter by signature, address or any field in the event.

Step 9 - Investigate an alert

Click any alert to open the full record behind it. EveBox shows the timestamp, protocol, source and destination with ports, the capture interface and flow ID, alongside the signature, its category, severity and signature ID. Where Suricata captured related context, such as DNS hostnames, HTTP transactions or extracted files, it appears in the tabs at the bottom, so you can see not just that something matched but what the traffic actually was.

Use Escalate to flag an alert for follow up, Archive to clear it once handled, and Add Comment to leave a note for whoever picks it up next.

Step 10 - Browse the raw event stream

The Events view shows everything Suricata is writing, not only alerts. Flow records, HTTP transactions, DNS queries, TLS handshakes and file metadata all appear here, and the Event Type filter narrows to one kind. This is where you go to understand normal traffic on the instance, or to find the surrounding context for an alert you are investigating.

The Alerts view is the complementary one: every alert regardless of inbox state, grouped by signature, which is the quickest way to see what is matching most often.

Keeping the ruleset current

The image ships the Emerging Threats open ruleset as it stood when the image was built. New signatures are published continually, so refresh it regularly:

sudo suricata-update
sudo systemctl restart suricata

To automate it, add a weekly systemd timer or cron entry that runs those two commands. You can also add other rule sources with sudo suricata-update enable-source <name>; list what is available with sudo suricata-update list-sources.

Your own local rules can go in /var/lib/suricata/rules/, added to the rule-files list in /etc/suricata/suricata.yaml. The shipped self test rule at /var/lib/suricata/rules/cloudimg-selftest.rules is a working example of the format.

Where the data lives

Suricata writes its event stream to /var/log/suricata/eve.json and EveBox indexes it into /var/lib/evebox. Both grow with traffic volume, so on a busy sensor watch disk usage and consider attaching a larger data disk. Suricata's own logrotate configuration manages eve.json; EveBox applies its own retention to the indexed events.

To confirm both sides are healthy at any time:

systemctl is-active suricata evebox && ls -lh /var/log/suricata/eve.json

Enabling HTTPS for production

The console is served over plain HTTP on port 80. For anything beyond a trusted network, put TLS in front of it: point a DNS name at the instance and terminate TLS with Azure Application Gateway or Azure Front Door, or install a certificate directly in the nginx site at /etc/nginx/sites-available/cloudimg-evebox. Keep the Basic authentication in place; TLS protects the credentials in transit, it does not replace them.

Support

cloudimg provides 24/7 support for this image. Contact support@cloudimg.co.uk.