Strelka on Ubuntu 24.04 LTS on Azure User Guide

Overview

This guide covers the deployment and use of Strelka on Ubuntu 24.04 LTS on Microsoft Azure using cloudimg'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 cloudimg 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. Because a file scanning service accepts arbitrary uploads, cloudimg does not rely on that login. The web interface is fronted by nginx with HTTP Basic authentication, and the credential is generated uniquely for your VM at first boot. Every other service port, the gRPC submission port, PostgreSQL and both coordinators, is bound to localhost only and is not reachable from the network. Do not remove the nginx Basic authentication layer, and restrict inbound access to port 80 to trusted source addresses with an Azure Network Security Group rule.

Prerequisites

Before deploying this image, ensure you have:

1. An active Microsoft Azure subscription
2. Access to the Azure Portal or Azure CLI
3. An SSH key pair for Linux VM access
4. 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.

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

1. Navigate to the Azure Marketplace and search for "Strelka Ubuntu 24.04 cloudimg"
2. Select the image and click Create
3. Configure the basics:
4. Subscription: Select your Azure subscription
5. Resource Group: Create new or select existing
6. Virtual Machine Name: Enter a name for your VM
7. Region: Select your preferred Azure region
8. Size: Standard_D4s_v5 recommended
9. Under Administrator Account, select SSH public key and enter your key
10. Under Inbound Port Rules, allow SSH (port 22) from your trusted IP only. You will add a rule for port 80 in Step 4.
11. Click Review + Create, then Create

Option B: Azure CLI

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

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

Step 2: Connect via SSH

Once your VM is running, connect using SSH:

ssh azureuser@<public-ip>

To find your VM's public IP:

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 connecting. Early connection attempts may produce permission denied errors while cloud init completes initial provisioning.

Step 3: Retrieve Your Web Credential

The web interface username and password were generated uniquely for this VM at first boot and written to a root only file. Read them with:

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 cloudimg customer or image. The same message is printed at login through the message of the day.

Step 4: Open the Web Interface to Trusted Sources

The interface listens on port 80. Add a Network Security Group rule allowing 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 presents an HTTP Basic authentication prompt. Enter the strelka username and the per VM password from strelka-credentials.txt.

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

Step 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, any YARA matches, and a Submission File Flow graph. The graph is the clearest view of recursive decomposition: an outer archive is shown extracting an inner archive, which in turn extracts the plain files inside it, each drawn as its own node with its own hash and scan results.

Step 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 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, scan.zip.files 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.

Step 7: Add Your Own YARA Rules

Strelka ships with a single placeholder YARA rule so the scanner chain is testable 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. Keep an eye on the container logs the first time to confirm 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

Filesystem Layout

Key directories:

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

Managing the Service

The stack is managed as a single systemd service that drives Docker Compose:

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

To inspect the individual containers:

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, set the replica count (budget roughly 1 GB of RAM per replica), and restart:

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 because clamd's 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 by uncommenting the ScanClamav block in /etc/strelka/configs/python/backend/backend.yaml and restarting the stack. The other 67 scanners, including the recursive archive extraction that is Strelka's core differentiator, are always active.

Scripts and Log Files

On Startup

On the first boot of every VM, strelka-firstboot.service runs before any container starts and generates 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 is restored automatically on every subsequent reboot.

OS security patching is handled by Ubuntu's unattended-upgrades, which 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:

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. Enter the strelka username and the per VM password from /root/strelka-credentials.txt at the browser credential prompt. If you have lost the password, read the file again over SSH.

The web interface is unreachable

Confirm 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 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, which submits a real archive and asserts 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 authentication is enforced and files are genuinely scanned end to end.

Security Recommendations

1. Restrict inbound access to port 80 to trusted source addresses with a Network Security Group rule. Never expose the interface to the whole internet.
2. Do not remove the nginx HTTP Basic authentication layer. Strelka's own login does not verify passwords without LDAP.
3. Keep the gRPC submission port (57314) and the database bound to localhost, as shipped. They are not authenticated and must never be exposed.
4. Rotate the per VM web credential if it is ever shared: update /etc/nginx/.strelka.htpasswd with htpasswd and reload nginx.
5. Keep the OS current. Unattended security upgrades are enabled by default.
6. Only submit files you are authorised to analyse, and remember that extracted children are written to the VM during scanning.

Support

cloudimg provides 24/7 support with a guaranteed 24 hour response SLA for this image. For assistance with deployment or configuration, contact support through the cloudimg 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.