Anubis Web AI Firewall on AWS User Guide

Overview

This guide covers deploying and operating Anubis on AWS from the cloudimg AWS Marketplace listing. Anubis is the open source Web AI Firewall: a single Go binary that runs 24/7 under systemd, sits in front of your application as a reverse proxy, and weighs the soul of every incoming request to keep AI scrapers and abusive crawlers off your site. Normal visitors flow straight through to your upstream; suspicious browsers are served a lightweight proof of work challenge; and known AI crawler user agents are blocked outright, so aggressive bots stop hammering your site and running up your bandwidth.

The image installs the latest stable Anubis release, resolved at build time from the official GitHub release package and baked reproducibly into the AMI (the exact version is recorded in /opt/anubis/VERSION). Anubis runs under systemd as the unit anubis@default.service and reverse proxies to a target upstream that you point at your own application.

HTTPS out of the box. In this image nginx terminates TLS on port 443 and reverse proxies to Anubis on the loopback interface. On the very first boot the image generates a fresh per instance self signed certificate (its Subject Alternative Names cover the instance public IP, hostname and loopback), so no default certificate ships inside the AMI. You replace it with a CA signed certificate for your own domain in production.

No default secret ships in the image. Anubis signs the cookies it issues to challenged visitors with an ED25519 key. This image generates that key per instance on the first boot straight into /etc/anubis/default.env (owned by root, not world readable, injected into the service by systemd). The shipped AMI carries only a placeholder, so no two instances ever share a signing key.

You bring your own upstream. Anubis protects whatever you set as its TARGET. The image ships a small local demo upstream so you can see the firewall working the moment it boots, and you repoint TARGET at your own application after launch.

What is included:

• The latest stable Anubis release (single Go binary), run under systemd as anubis@default.service

• nginx terminating TLS on :443 with a per instance self signed certificate regenerated on first boot, reverse proxying to Anubis on 127.0.0.1:8923

• An unauthenticated /healthz load balancer probe and a 301 redirect to HTTPS on :80, plus a local demo upstream on 127.0.0.1:8000

• The built in default bot policy: allow normal visitors, challenge suspicious browsers with proof of work, and deny known AI scrapers (Amazonbot, Bytespider, GPTBot family, anthropic-ai, PerplexityBot, Scrapy and many more)

• Prometheus metrics on 127.0.0.1:9090 showing how many requests were allowed, challenged and denied, broken down by rule

• A per instance ED25519 signing key generated on first boot into /etc/anubis/default.env, rendered from a placeholder template so the shipped AMI carries no key

• Ubuntu 24.04 LTS base with the latest security patches applied at build time and unattended security updates enabled

• 24/7 cloudimg support with a guaranteed 24 hour response SLA

Connecting to your instance

Anubis is a headless appliance: you administer it over SSH and reach the firewall over HTTPS. SSH in as the default login user for the operating system variant you launched.

The instance security group must allow TCP 22 (admin), TCP 443 (the firewall over HTTPS) and TCP 80 (the HTTP to HTTPS redirect and the health probe) from the networks your visitors and administrators connect from.

Prerequisites

• An AWS account subscribed to the Anubis listing on AWS Marketplace, and an EC2 key pair in the target region

• An application (upstream) you want to protect, and a DNS domain you can point at the instance for production

Recommended instance type: m5.large (2 vCPU, 8 GB RAM) is ample for a firewall fronting a typical site. Anubis is stateless (its challenge state is in memory), so it scales with CPU and memory. For heavier traffic move up the m5 family.

Step 1: Launch from AWS Marketplace

Subscribe to Anubis on AWS Marketplace (published by cloudimg), then launch the Ubuntu 24.04 AMI with your key pair and a security group that opens ports 22, 80 and 443 as described above. You can also launch from the CLI:

aws ec2 run-instances --region us-east-1 \
  --image-id <ami-id> --instance-type m5.large \
  --key-name <your-key> --security-group-ids <security-group-id> \
  --subnet-id <subnet-id> \
  --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=anubis-01}]'

Anubis starts automatically on first boot: the per instance ED25519 signing key and TLS certificate are generated, then anubis@default.service and nginx.service come up.

Step 2: Verify the Anubis and nginx services

Connect over SSH, then confirm both services are active and see which ports are bound. nginx listens on :443 (TLS) and :80 (redirect and health probe), Anubis listens on 127.0.0.1:8923 (the proxy) and 127.0.0.1:9090 (metrics), and the demo upstream on 127.0.0.1:8000:

sudo systemctl is-active anubis@default nginx
anubis --version
sudo ss -tlnp | grep -E ':443|:80 |:8923|:9090|:8000'
cat /opt/anubis/VERSION

Step 3: See a normal visitor proxied to the app

Anubis classifies every request. A normal, non browser client is allowed and proxied straight through to your upstream. Test it on the instance with curl (the image uses a per instance self signed certificate, so pass -k):

BODY="$(curl -sk -A 'cloudimg-health/1.0' https://127.0.0.1/)"
printf '%s\n' "$BODY" | grep -q 'cloudimg Anubis demo upstream' && echo 'normal visitor: ALLOWED, proxied to the protected upstream'
curl -sk -o /dev/null -w 'GET https://127.0.0.1/ -> HTTP %{http_code}\n' -A 'cloudimg-health/1.0' https://127.0.0.1/

The request reaches the bundled demo upstream and returns HTTP 200. Once you repoint TARGET at your own application (Step 6), your real service is what allowed visitors see.

Step 4: See an AI scraper blocked

Now send the same request with a known AI scraper user agent. Anubis serves it the block/challenge interstitial and never proxies it to your upstream:

BOT="$(curl -sk -A 'Amazonbot/0.1 (+http://example.com/bot)' https://127.0.0.1/)"
printf '%s\n' "$BOT" | grep -q 'Oh noes' && echo 'Amazonbot: BLOCKED by the AI firewall (served the Anubis interstitial)'
printf '%s\n' "$BOT" | grep -q 'cloudimg Anubis demo upstream' && echo 'reached upstream (unexpected)' || echo 'Amazonbot never reached the protected upstream'

The Amazonbot request is served the Anubis interstitial and does not touch your application. This is the core of Anubis: real visitors are unaffected while automated AI crawling is stopped at the door. A real browser is instead served a lightweight proof of work challenge that it solves transparently in JavaScript before it is let through.

Step 5: Inspect the classification metrics

Anubis exposes Prometheus metrics on 127.0.0.1:9090. The anubis_policy_results counter shows how many requests each policy rule allowed, challenged or denied, so you can see the firewall working and wire it into your monitoring:

M="$(curl -s http://127.0.0.1:9090/metrics)"
printf '%s\n' "$M" | grep -E '^anubis_policy_results|^anubis_challenges_issued' | head -15 || true

You will see anubis_policy_results broken down by rule and action (for example bot/ai-catchall for the AI scraper denials), alongside anubis_challenges_issued. These are standard Prometheus counters you can scrape from your existing stack.

Step 6: Understand the per instance key and configuration

Anubis is configured through the environment file /etc/anubis/default.env, which systemd injects into the service. This image generates the ED25519 signing key on first boot into that file (owned by root, mode 0600); the shipped AMI carries only a placeholder. The endpoints for this instance are summarised in a root only file, and the per instance TLS certificate covers this instance:

sudo grep -E '^BIND|^TARGET|^METRICS_BIND|^DIFFICULTY' /etc/anubis/default.env
sudo stat -c '%n  mode=%a  owner=%U:%G' /etc/anubis/default.env /root/anubis-credentials.txt
sudo openssl x509 -in /etc/nginx/certs/cert.pem -noout -subject

BIND is Anubis on loopback :8923, TARGET is the upstream Anubis protects, METRICS_BIND is :9090, and DIFFICULTY is the proof of work difficulty. The ED25519_PRIVATE_KEY_HEX line in the same file holds the per instance signing key (mode 0600, not shown here). The credentials file lists this instance's access URL, and the certificate covers this instance.

Step 7: Protect your own application

To put Anubis in front of your own application, point TARGET at your upstream and restart the service. Set TARGET to wherever your application listens, for example a local app on http://127.0.0.1:3000 or another host such as http://<private-ip>:8080:

# Edit /etc/anubis/default.env and change the TARGET= line to your upstream, e.g.
#   TARGET=http://<private-ip>:8080
sudo sed -i 's#^TARGET=.*#TARGET=http://<private-ip>:8080#' /etc/anubis/default.env
sudo systemctl restart anubis@default

Anubis now proxies allowed traffic to your application and blocks AI scrapers in front of it. Because nginx terminates TLS and forwards the real client IP to Anubis in the X-Forwarded-For header, your policy decisions and logs see the true visitor address.

Step 8: Tune the bot policy

The built in default policy already allows normal visitors, challenges suspicious browsers and denies a large list of known AI scrapers. To customise it, author your own policy file and reference it from the environment by adding a POLICY_FNAME=/etc/anubis/default.botPolicies.yaml line to /etc/anubis/default.env, then restart Anubis. Policies can allow, weigh (challenge based on accumulated suspicion) or deny by user agent, path, header, IP range and more. Start from the upstream default policy documented at the Anubis project site. Leaving POLICY_FNAME unset keeps the sensible built in default.

Step 9: Use your own domain and a trusted certificate (production)

The self signed certificate is a convenience for getting started. For production, point a DNS name you control (<your-domain>) at the instance public IP and replace the certificate:

• Drop a CA signed certificate and key into /etc/nginx/certs/cert.pem and /etc/nginx/certs/key.pem, then sudo systemctl reload nginx. You can obtain one with certbot for <your-domain> or from your own CA.

• Alternatively front the instance with an Application Load Balancer terminating ACM certificates and forward to nginx on :443.

• Visitors then reach your site at your own domain with no certificate trust step, and Anubis keeps the scrapers out.

Step 10: Server components

Step 11: Managing the Anubis service

sudo systemctl status anubis@default --no-pager | head -12
sudo systemctl is-active anubis@default nginx

Apply a configuration change with sudo systemctl restart anubis@default, reload the nginx helper with sudo systemctl reload nginx, and follow the logs live with sudo journalctl -u anubis@default -f. The configuration lives at /etc/anubis/default.env. After any change, restart Anubis.

Step 12: Security recommendations

• Restrict the security group. Allow TCP 443 (and 22 for admin) only from the networks your visitors and administrators connect from.

• Use a trusted certificate and your own domain (Step 9) so visitors validate the site without a manual trust step.

• Point TARGET at your real application and remove the demo upstream from production use.

• Tune the policy for your traffic (Step 8). Start from the built in default and add allow rules for any legitimate automation you rely on, and stricter rules for abusive ranges.

• Protect the key. /etc/anubis/default.env holds the ED25519 signing key and is mode 0600; keep it that way and regenerate it if an instance is ever exposed.

• Keep the OS patched. Unattended security upgrades remain enabled on the running instance.

Step 13: Support and Licensing

Anubis is distributed under the MIT License. This cloudimg image bundles the unmodified official open source release; cloudimg provides the packaging, hardening, per instance key and TLS automation, the working demo upstream, and 24/7 support with a guaranteed 24 hour response SLA. Anubis is an independent open source project by Techaro and this image is not affiliated with or endorsed by Techaro or the Anubis project.

Need Help?

Email support@cloudimg.co.uk for deployment help, configuration questions, or licensing enquiries.