SecureAnyCloud
Deployment guide

EveBox

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 is only 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 and matches it against the Emerging Threats open ruleset. It 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. It presents the events as a searchable analyst inbox in the browser.

The image is secure by default. EveBox is bound only to the loopback interface and is fronted by nginx on port 80 with HTTP Basic authentication. The password is generated on first boot, is unique to each instance, and is 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, nobody can bypass the authentication by reaching the application port directly.

What you get:

  • 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 verify the whole capture, index and display chain with one command
  • An Ubuntu 24.04 LTS base, patched at build time, with unattended security upgrades enabled
  • 24/7 SecureAnyCloud 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 SecureAnyCloud and is not affiliated with or endorsed by the EveBox or Suricata projects.

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a 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.

In the network security group (NSG), allow inbound 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.

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 SecureAnyCloud, and select Create.

On the Basics tab, 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).

Select Review + create, then Create.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:evebox-ubuntu-24-04:default:latest
az vm create \
  --resource-group <your-rg> \
  --name evebox \
  --image sac1647283583153:evebox-ubuntu-24-04:default:latest \
  --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, which only root can read:

cat /root/evebox-info.txt

The file also records where Suricata writes 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, run:

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 SecureAnyCloud. It fires only when you send the probe deliberately, so it adds no noise to ordinary traffic.

The test exercises 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":"sac 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 that EveBox has indexed the alert and serves 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))"

The list shows SecureAnyCloud EveBox pipeline self-test, 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. It lists every alert Suricata has raised, newest first, grouped by signature with a count, the source and destination addresses, and the time.

From the Inbox you can Archive an alert you have dealt with, or Escalate one that needs follow-up. Escalated alerts get their own view. 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, and the signature with 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. 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 writes, not only alerts. Flow records, HTTP transactions, DNS queries, TLS handshakes and file metadata all appear here, and the Event Type filter narrows the list to one kind. Use this view to understand normal traffic on the instance, or to find the context around an alert you are investigating.

The Alerts view is the complement. It lists every alert regardless of inbox state, grouped by signature, which is the quickest way to see what matches 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 the ruleset 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/sac-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, and 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/sac-evebox. Keep the Basic authentication in place. TLS protects the credentials in transit, but it does not replace them.

Support

SecureAnyCloud provides 24/7 support for this image. Contact sales@secureanycloud.com.

Deploy on Azure

Launch EveBox on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure