Scirius Community Edition on Ubuntu 24.04 LTS on Azure

This image ships Scirius Community Edition 3.8.0 and the Suricata IDS engine on Ubuntu 24.04 LTS as a single-node Suricata ruleset-management appliance, ready to use from the first boot of every deployed virtual machine.

Scirius Community Edition is a web interface, developed by Stamus Networks, that is dedicated to managing a Suricata ruleset. You add rule Sources (public feeds such as the Emerging Threats Open ruleset, or your own custom sources), compose them into a Ruleset with per-category and per-rule control, and push that ruleset to a running Suricata engine — which this image reloads live. It is the organised, repeatable way to curate exactly what your intrusion-detection engine detects, instead of hand-editing rule files.

What this appliance is, and what it is not

This image ships the rule-management core of Scirius CE: Sources, Rulesets, the Suricata instance link, and the live rule push. The stack is Suricata (from the Ubuntu archive, so it stays patchable) plus Scirius served by gunicorn behind nginx, backed by SQLite.

Scirius CE also has an event-analytics "Hunt" dashboard that renders Suricata alerts and flows. That feature is built on an Elasticsearch datastore, which is not open source under an OSI-approved licence, so this image intentionally does not enable it and installs no Elasticsearch or OpenSearch. The rule-management workflow — the reason most teams run Scirius — is fully functional; the alert-analytics graphs simply report no data because there is no event store behind them. If you need event analytics, pair this appliance with your own separately-licensed analytics stack.

First boot: what happens automatically

There is no default administrator and no shared secret in this image. On the first boot of each virtual machine a one-shot service:

• generates a fresh Django secret key unique to this machine,
• initialises an empty database and creates a unique administrator account with a strong random password,
• fetches the current Emerging Threats Open ruleset directly onto your machine (rather than shipping a ruleset frozen at build time, which would already be stale), composes it into a Default ruleset, registers the Suricata engine, and pushes the ruleset so Suricata is armed with current signatures,
• writes the credentials to a root-only file.

Because the ruleset is fetched on your own machine, the signatures come from the provider, under the provider's terms, and are current on the day you deploy.

1. Connect and retrieve your credentials

Connect over SSH with the key you selected at deployment, then read the per-VM credentials file:

sudo cat /root/scirius-credentials.txt

This prints the admin username (admin), the unique password generated for this machine, a REST API token, and the sign-in URL. Keep it somewhere safe.

2. Confirm the appliance is running

The three services that make up the appliance should all be active:

sudo systemctl is-active suricata scirius nginx

Each line should read active.

Scirius answers on port 80 through nginx; the application server itself binds only to loopback. Confirm the web UI is serving:

curl -s -o /dev/null -w 'scirius login page: HTTP %{http_code}\n' http://127.0.0.1/accounts/login/

You should see HTTP 200.

3. Open the Scirius web UI

Open http://<your-vm-public-ip>/ in a browser. You are redirected to the sign-in page shown above. Sign in as admin with the password from /root/scirius-credentials.txt.

To reach the appliance you must allow inbound TCP 80 (and 22 for SSH) to the VM in its Azure Network Security Group. For a public deployment, restrict the source ranges to your own networks and put TLS in front (see section 7).

4. Manage rule Sources

The Sources page lists the rule feeds Scirius knows about. First boot has already added and fetched the ETOpen Ruleset feed for you.

From here you can add more public feeds (Add Public Source) or your own custom source (Add Custom Source), and refresh a source to pull its latest rules. Scirius versions each source in a local git repository so you can see exactly what changed between updates.

5. Compose and inspect the Ruleset

The Rulesets page shows the composed rulesets. First boot created the Default ruleset from the ETOpen source.

Opening a ruleset shows every category it draws from and the total rule count, and lets you enable or disable whole categories, apply transformations (for example converting alert rules to drop rules for an inline IPS deployment), and export the generated rules file.

6. Verify Suricata is armed with the pushed ruleset

Every time you push a ruleset, Scirius writes it to /var/lib/scirius/rules/scirius.rules and this appliance reloads Suricata live. Confirm the engine is loaded with the pushed rules:

wc -l < /var/lib/scirius/rules/scirius.rules

This prints the number of rules Scirius has pushed (tens of thousands with the full ETOpen ruleset). Confirm Suricata accepts that ruleset:

sudo suricata -T -c /etc/suricata/suricata.yaml

It should report that the configuration and rules loaded successfully.

Suricata is configured to read its ruleset from the directory Scirius pushes to (default-rule-path: /var/lib/scirius/rules, rule-files: [scirius.rules]), so the web UI is the single source of truth for what the engine detects.

7. Administer from the command line

Scirius ships a management CLI so you can drive the same operations from a script or a scheduled job:

sudo scirius-manage help 2>&1 | head -20

For example, to re-fetch every source and push the refreshed ruleset to Suricata in one step you would run sudo scirius-manage updatesuricata. (This reaches out to the rule providers over the network, so it is not run as part of this walk-through.)

8. No Elasticsearch is installed

You can confirm the appliance ships the rule-management core only, with no Elasticsearch/OpenSearch datastore:

dpkg -l 2>/dev/null | grep -icE '^ii  (elasticsearch|opensearch)' || echo 0

This prints 0 — nothing from the Elasticsearch/OpenSearch family is installed, and nothing listens on the Elasticsearch port.

9. Secure by default

No two deployments of this image ever share a secret. The secret key and administrator password are generated on each machine's own first boot, and the shipped image contains no database, no administrator and no usable credential.

For a production deployment:

• Put TLS in front of nginx (terminate HTTPS with your own certificate, or add a reverse proxy / Azure Application Gateway) and restrict the Network Security Group to your own source ranges.
• Change the administrator password after first sign-in, and create individual accounts for your team from the admin area.
• Keep the operating system current — unattended security upgrades are enabled, and Suricata is installed from the Ubuntu archive so it is patched through the same path.

Support

This is a repackaged open source product (Scirius CE is GPL-3.0; Suricata is GPL-2.0) with additional charges for cloudimg support services. Our engineers provide 24/7 support for deployment, upgrades, TLS termination, custom rule sources, Suricata tuning and scaling. Scirius and Suricata are trademarks of their respective owners; use of the names here is nominative and does not imply affiliation or endorsement.