SecureAnyCloud
Deployment guide

Strelka

Overview

This guide covers the deployment and use of Strelka on Ubuntu 24.04 LTS on Microsoft Azure using SecureAnyCloud's pre configured virtual machine image from the Azure Marketplace. Strelka is a container based file scanning and analysis system built by Target's security team for threat hunting, threat detection and incident response. Files are submitted to a Go frontend, distributed through a coordinator to Python backend workers, and scanned by a library of specialised scanners. Its defining behaviour is recursive decomposition: when a scanner extracts children from an archive, an installer, an email or an embedded object in a document, each child is resubmitted and scanned in its own right, so a threat buried several layers inside a file is surfaced rather than hidden by its wrapper. Every scan returns structured JSON, one event per file at every depth, carrying hashes, file type, entropy, metadata and YARA matches.

What's included in this VM image:

  • Strelka 1.0.1 running the full single node topology as seven containers (frontend, backend, manager, coordinator, event cache, PostgreSQL and web UI)
  • A web interface fronted by nginx with HTTP Basic authentication, protected by a credential generated uniquely for your VM at first boot
  • All container images pinned by digest and pre pulled, so the stack starts without contacting a registry
  • Per VM secrets (web credential, database password and session signing key) generated on first boot, never baked into the image
  • The strelka-oneshot command line submission tool for scripted scanning
  • A 4 GiB swapfile provisioned as headroom for recursive file carving
  • The full Apache 2.0 licence text and upstream attribution notices at /etc/strelka/licenses
  • Docker Engine and the Compose plugin
  • Azure Linux Agent (waagent) and cloud init for Azure integration
  • Latest security patches applied at build time with unattended upgrades enabled
  • 24/7 SecureAnyCloud support with a guaranteed 24 hour response SLA

Platform: Microsoft Azure (Gen2 Hyper V) Default user: azureuser Web UI: http://<public-ip>/ (HTTP Basic auth, port 80) Credentials file: /root/strelka-credentials.txt Configuration: /etc/strelka

A note on authentication before you begin

Strelka's own web login does not verify passwords unless an LDAP server is configured, and no LDAP server is configured by default. On its own, the login form would accept any username and any password. A file scanning service accepts arbitrary uploads, so SecureAnyCloud does not rely on that login.

Instead, nginx fronts the web interface with HTTP Basic authentication, and the credential is created uniquely for your VM at first boot. Every other service port is bound to localhost only and is not reachable from the network. This covers the gRPC submission port, PostgreSQL and both coordinators.

Do not remove the nginx Basic authentication layer. Restrict inbound access to port 80 to trusted source addresses with an Azure Network Security Group rule.

Prerequisites

Before you deploy this image, make sure you have:

  • An active Microsoft Azure subscription
  • Access to the Azure Portal or Azure CLI
  • An SSH key pair for Linux VM access
  • A trusted source IP range to which you will restrict inbound access to port 80

Recommended VM size: Standard_D4s_v5 (4 vCPU, 16 GB RAM) or larger. Real analysis workloads recursively decompose archives and stage extracted children in memory, so 4 GB is adequate only for light use. The image runs on smaller sizes, but throughput and the ability to handle large nested files improve substantially with more memory.

1

Deploy the virtual machine

Option A: Azure Portal

  • Open the Azure Marketplace and search for "Strelka Ubuntu 24.04 SecureAnyCloud".
  • Select the image and choose Create.
  • On the Basics tab, set Subscription to your Azure subscription.
  • Set Resource Group to a new or existing group.
  • Enter a name in Virtual Machine Name.
  • Select your preferred Azure region under Region.
  • Set Size to Standard_D4s_v5 (recommended).
  • Under Administrator Account, select SSH public key and enter your key.
  • Under Inbound Port Rules, allow SSH (port 22) from your trusted IP only. You add a rule for port 80 in Step 4.
  • Select Review + Create, then Create.

Option B: Azure CLI

az vm image terms accept --urn sac1647283583153:strelka-ubuntu-24-04:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-strelka-vm \
  --image sac1647283583153:strelka-ubuntu-24-04:default:latest \
  --size Standard_D4s_v5 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

The first boot creates the per-VM secrets and starts the seven containers. Allow two to three minutes after the VM reaches a running state before you open the web interface.

2

Connect via SSH

When your VM is running, connect over SSH:

ssh azureuser@<public-ip>

To find your VM's public IP address:

az vm show --resource-group myResourceGroup --name my-strelka-vm --show-details --query publicIps -o tsv

To switch to the root user:

sudo su -

Important: Wait for the VM to reach a running state before you connect. Early connection attempts may fail with permission denied errors while cloud-init completes initial provisioning.

3

Retrieve your web credential

The first boot created a username and password for the web interface, unique to this VM, and wrote them to a root-only file. Read the file with sudo:

sudo cat /root/strelka-credentials.txt

The file contains the web URL, the username (strelka) and the per-VM password. These credentials are not shared with any other SecureAnyCloud customer or image. The same message is printed at login through the message of the day.

4

Open the web interface to trusted sources

The interface listens on port 80. Add a Network Security Group rule that allows inbound TCP 80 from your trusted source range only. Then open the URL from strelka-credentials.txt in a browser.

az network nsg rule create \
  --resource-group myResourceGroup \
  --nsg-name my-strelka-vmNSG \
  --name allow-strelka-web \
  --priority 1010 \
  --destination-port-ranges 80 \
  --source-address-prefixes <your-trusted-cidr> \
  --access Allow --protocol Tcp --direction Inbound

When you browse to the URL, your browser shows an HTTP Basic authentication prompt. Enter the strelka username and the per-VM password from strelka-credentials.txt.

After the browser prompt, the Strelka login page loads. Enter the same strelka username and per-VM password again. The dashboard then opens with submission counters and the file upload area.

5

Submit a file for scanning

Drag a file onto the Upload File area on the dashboard, or click the area to browse for one. Strelka scans the file, recursively decomposes any archive or container format it finds, and records one result per file at every depth. When the submission appears in the Analysis Submissions table, click it to open the result.

The detail page shows the submitted file's hashes, its detected type, the scanners that ran and any YARA matches. It also shows a Submission File Flow graph, which is the clearest view of recursive decomposition. An outer archive extracts an inner archive, which in turn extracts the plain files inside it. Each file is drawn as its own node with its own hash and scan results.

6

Submit a file from the command line

The image includes the strelka-oneshot tool for scripted submission. It talks to the frontend over the internal container network and prints the JSON event tree to standard output. Run it as root so that it can read the compose environment:

sudo su - NET=strelka_net docker run --rm --network "$NET" -v /path/to/samples:/data:ro \
  target/strelka-oneshot -s frontend:57314 -f /data/yourfile.zip -l - -t 120

Each line of output is a JSON event for one file. The file.depth field is 0 for the file you submitted and increases for each extracted child. The scan.zip.files field lists the members of an archive, scan.hash.sha256 carries each file's SHA256, and scan.yara.matches lists any YARA rule hits. Pipe the output through jq to explore it.

7

Add your own YARA rules

Strelka ships with a single sample YARA rule, so you can test the scanner chain out of the box. Add your own rules to make detection meaningful. Rules live under the mounted configuration directory:

sudo su - ls /etc/strelka/configs/python/backend/yara/
# add your .yara files alongside rules.yara, then restart the stack systemctl restart strelka

The backend recompiles the rule set when it restarts. The first time, check the container logs to confirm that your rules compiled:

cd /etc/strelka set -a; . /etc/strelka/strelka.env; set +a docker compose -f /etc/strelka/compose.yaml logs --tail 50 backend

Server components

Component Description

frontend Go service accepting file submissions over gRPC (localhost:57314)

backend Python scanning workers that decompose and scan each file

manager Coordinator housekeeping service

coordinator Valkey instance distributing work to backends

gatekeeper Valkey instance caching scan events

postgresdb PostgreSQL store for the web UI's submission metadata

ui Web interface, reached through nginx on port 80

nginx HTTP Basic authentication front door on port 80

Filesystem layout

Mount Size Description

/ 29 GB Root filesystem

/boot 881 MB Operating system kernel files

/boot/efi 105 MB UEFI boot partition (Gen2 Hyper-V)

/mnt varies Azure temporary resource disk

Key directories:

Path Description

/etc/strelka Compose file, per-VM environment and configuration

/etc/strelka/configs Upstream Strelka backend and frontend configuration

/etc/strelka/configs/python/backend/yara YARA rules loaded by the scanner

/etc/strelka/licenses Full Apache 2.0 license text and upstream NOTICE files

/root/strelka-credentials.txt Per-VM web credential (root only)

/usr/local/sbin/strelka-roundtrip.sh Self-verification script for the running stack

A 4 GiB swapfile at /swapfile is provisioned as headroom for recursive file carving.

Managing the service

A single systemd service manages the stack and drives Docker Compose:

sudo systemctl status strelka
sudo systemctl restart strelka
sudo systemctl stop strelka

To inspect the individual containers, run:

sudo su - set -a; . /etc/strelka/strelka.env; set +a docker compose -f /etc/strelka/compose.yaml ps

Raising scanning throughput

The scanning backend runs as a single worker by default, which suits the smaller VM sizes. On a larger VM, you can add workers. Edit the compose file, uncomment the deploy block on the backend service and set the replica count (budget roughly 1 GB of RAM per replica). Then restart the service:

sudo nano /etc/strelka/compose.yaml
# under the backend service, uncomment:
# deploy:
# replicas: 2
sudo systemctl restart strelka

Re-enabling ScanClamav

ClamAV signature scanning is disabled in this image. The clamd in-memory signature database needs 1 to 2 GB of RAM on its own and downloads signatures at start, which does not suit the smaller VM sizes. On a larger VM, you can re-enable it. Uncomment the ScanClamav block in /etc/strelka/configs/python/backend/backend.yaml and restart the stack.

The other 67 scanners are always active. They include the recursive archive extraction that is Strelka's core differentiator.

Scripts and log files

Path Description

/usr/local/sbin/strelka-firstboot.sh Creates the per-VM secrets on first boot

/usr/local/sbin/strelka-roundtrip.sh Verifies auth and a real recursive scan end to end

/var/lib/sac/data/strelka-firstboot.done First boot sentinel

/etc/strelka/strelka.env Per-VM secrets, mode 0600 root only

/etc/systemd/system/strelka-firstboot.service First-boot secret creation unit

/etc/systemd/system/strelka.service Docker Compose stack unit

On startup

On the first boot of every VM, strelka-firstboot.service runs before any container starts. It creates the per-VM web credential, database password and session signing key. strelka.service is gated on the resulting environment file, so the Strelka stack cannot start before those secrets exist. Both units are enabled, so the stack comes back automatically on every later reboot.

Ubuntu's unattended-upgrades handles OS security patching. It is enabled in this image and installs security updates automatically. To review or change its schedule, edit /etc/apt/apt.conf.d/20auto-upgrades. To apply all pending updates immediately, run:

sudo apt-get update && sudo apt-get -y upgrade

Troubleshooting

The web interface returns 401 and will not accept the login form

The 401 comes from the nginx HTTP Basic authentication layer, before the login form. At the browser credential prompt, enter the strelka username and the per-VM password from /root/strelka-credentials.txt. If you have lost the password, read the file again over SSH.

The web interface is unreachable

Confirm that the Network Security Group allows inbound TCP 80 from your address and that the stack is up:

sudo systemctl status strelka curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1/
# expect 401

A 401 from the localhost check confirms that nginx and the front door are healthy.

A submission never completes

Check the backend container logs for scanner errors:

sudo su - set -a; . /etc/strelka/strelka.env; set +a docker compose -f /etc/strelka/compose.yaml logs --tail 100 backend

Confirm the whole pipeline works

Run the built-in self-verification. It submits a real archive and asserts that the extracted child's hash matches an independently computed one:

sudo /usr/local/sbin/strelka-roundtrip.sh

A line beginning OK strelka round-trip confirms that authentication is enforced and that files are scanned end to end.

Security notes

  • Restrict port 80. Limit inbound access to trusted source addresses with a Network Security Group rule. Never expose the interface to the whole internet.
  • Keep nginx authentication. Do not remove the nginx HTTP Basic authentication layer. Strelka's own login does not verify passwords without LDAP.
  • Keep internal ports on localhost. Leave the gRPC submission port (57314) and the database bound to localhost, as shipped. They are not authenticated and must never be exposed.
  • Rotate the web credential if it is shared. Update /etc/nginx/.strelka.htpasswd with htpasswd and reload nginx.
  • Keep the OS current. Unattended security upgrades are enabled by default.
  • Submit only files you may analyze. Submit only files you are authorized to analyze, and remember that extracted children are written to the VM during scanning.

Support

SecureAnyCloud provides 24/7 support with a guaranteed 24 hour response SLA for this image. For assistance with deployment or configuration, contact support through the SecureAnyCloud listing on the Azure Marketplace.

This image is not affiliated with, endorsed by, or sponsored by Target Brands, Inc. The Strelka name is used nominatively to identify the open source software shipped in this image.

Deploy on Azure

Launch Strelka 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