Skip to content

NextronSystems/thunderstorm-deployment

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

35 Commits
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Deploy Thunderstorm as a Container

THOR Thunderstorm is a web service that lets you scan files with our compromise assessment tool THOR through a Web-API. This guide provides a base container image and a Docker Compose template so you can run Thunderstorm as a container with just providing your contract token.

Quick-Start

  1. Download the Docker Compose file
curl -O https://raw.githubusercontent.com/NextronSystems/thunderstorm-deployment/master/docker-compose.yml
  1. Get a contract token from the Nextron Portal (see Contract-Token)

  2. Start the service with your contract token

CONTRACT_TOKEN=<CONTRACT_TOKEN> docker compose up -d

Thunderstorm is exposed on port 8080 by default.

Contract-Token

Deploying Thunderstorm as a container requires a non-host-based Thunderstorm contract.

On first start, the container uses your contract token to download the THOR binaries and persists them in a Docker volume so subsequent restarts are instant. You can omit the contract token afterwards as long as the volume exists.

During that first download the Nextron Portal issues a license server-side. Two optional environment variables tune this:

  • LICENSE_HOSTNAME — host identity the portal binds the issued license to (default: thunderstorm-container). Keep it fixed so re-downloads reuse the same license slot instead of consuming new contract quota on every fresh volume.
  • LICENSE_COMMENT — comment shown for the issued license in the Nextron Portal.

A contract token can be retrieved from the Nextron Portal under Contracts & Licenses → Contracts → Actions → cloud icon → THOR Download Token.

Contract Token location in Nextron Portal

Tech-Preview

If you want to use the techpreview channel (currently THOR 11) you need to set TECHPREVIEW=1. If it is omitted it will downgrade to the stable channel again.

The compose file contains commented environment variables for all available configuration options. Some options only apply to specific THOR major versions, for example, QUEUE_WARN_SIZE is only available for THOR 11.

Signature Updates

THOR signatures are updated automatically on every container start. To keep them fresh without manually restart, set SIGNATURE_UPDATE_INTERVAL (in hours) to schedule recurring updates.

The update mechanism depends on the THOR major version. On THOR 10, new signatures only take effect after a restart. Docker's health check therefore marks the container as unhealthy once SIGNATURE_UPDATE_INTERVAL has elapsed, prompting Docker to restart it. The new signatures are then fetched as part of the regular container start, at the cost of a brief API downtime. THOR 11 uses Thunderstorm's built-in signature-update feature to download and apply signatures in-place, leaving the API available throughout.

Additional Arguments

If you need to customize the THOR scan behavior, you can pass additional arguments via THOR_ARGS environment variable. For example, to forward scan results to a remote SIEM:

environment:
  THOR_ARGS: "--remote-log splunk.intern:514:DEFAULT:TCP --remote-log elastic.intern:1514:JSON:TCP"

A full list of all supported arguments can be derived from the THOR binary using ./thor-linux-64 --fullhelp.

Security

The communication between a client and the Thunderstorm service could involve sensitive files. Therefore, we highly recommend to encrypt the traffic using TLS by mounting the certificate and private key via the built-in secrets functionality of Docker or Kubernetes into the container. In addition, you need to specify the file path to the TLS certificate and private key in the environment variables TLS_CERT and TLS_KEY.

Out of the box, Thunderstorm API is unauthenticated and does not support authentication providers at the moment. If you require an authentication layer, we suggest to use a proxy middleware which delegates the authentication to an external provider such as Microsoft Entra ID.

Limitations

Load-Balancing

Thunderstorm allows you to send asynchronous requests and poll the results using an ID. Currently, Thunderstorm instances do not share their results with each other. If you run multiple Thunderstorm containers behind a load-balancer and request the results of an async request, you may not get the result from the correct Thunderstorm instance. We recommend to use async requests in combination with remote logging only in a load-balancer setup.

About

Templates for deploying Thunderstorm in container environments

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors