Self-Hosted Deployment Hardening Guide

This guide is for teams operating a self-hosted (on-premises or private cloud) AIR Console, including 2-tier deployments with a separate Database Server. It covers network placement, access separation, perimeter protection, outbound control, data protection and monitoring for the AIR Console and Database Servers.

AIR SaaS runs inside an infrastructure that Binalyze operates and protects. A self-hosted deployment is operated by you, and its security posture depends on how the surrounding network is designed: where the Console and Database Servers sit, what can reach them, what they can reach, and who can log in.

The guide describes a reference set of controls for hardening a self-hosted AIR deployment. It complements, and does not replace, the product documentation linked under Related. The controls below reduce exposure but do not substitute for keeping AIR up to date.

The recommendations are vendor-neutral. Where a control is normally implemented in a firewall, load balancer or WAF, the rule is described in generic terms (source, destination, port, purpose) so that it can be applied on any platform.

Principles

The network is the primary control. When the Console is deployed behind a layer-7 load balancer, reverse proxy or WAF, the Console does not see the real client address; it sees the proxy. IP-based controls inside the product therefore cannot be relied on in that topology, and allowlists must be enforced at the network perimeter instead (see IP Restriction: when it works and when it does not).
Deny outbound traffic by default. The Console only needs to reach a short list of Binalyze services plus the integrations you have configured. Everything else should be blocked. This is the control that limits the impact of any credential or data exposure.
Separate the Responder surface from the management surface. Responders need to reach the Console; your analysts and administrators do not need to reach it from the internet. AIR can serve these two audiences on different ports, so that only the Responder surface is exposed.

Reference architecture

A hardened 2-tier deployment has the following shape:

Component	Network segment	Reachable from
AIR Console Server	DMZ / public-facing segment, behind a firewall (and ideally a WAF or load balancer)	Responders (internet and/or internal), management users via VPN or office network only
AIR Database Server	Private segment, no public IP address	AIR Console Server only (database port), administrators over SSH from the management network or VPN only
Management users (UI/API)	Office network or VPN	—
Responders	Internet and/or internal networks	—

Alternative: keep the Console off the internet entirely. Instead of exposing the Console, you can place a RelayPro server in the DMZ and keep the Console on the internal network. Responders authenticate to RelayPro, which forwards only authorised Responder traffic to the Console. This removes the Console from the public attack surface altogether and is the recommended model where it fits your licensing and operations. See RelayPro.

Network placement and inbound rules

Inbound rules for the Console Server

Source	Destination	Port / Protocol	Purpose	Required
Responders (internet / internal)	Console	TCP 443 (HTTPS)	Responder communication, evidence upload, interACT (WebSocket over HTTPS)	Yes
Responder networks only (internet / internal)	Console	TCP 4222 (NATS)	Real-time task delivery. Plain TCP (layer 4), not HTTP	Recommended
Management users (VPN / office only)	Console	TCP 8443 (HTTPS)	Console UI and API when the Console Port feature is enabled (see Enable the Console Port feature)	Yes, restricted
Administrators’ SSH clients (management network / VPN only)	Console	TCP 22 (SSH)	Server administration	Restricted
Anyone	Console	TCP 80 (HTTP)	Initial setup only. Close after installation	No (after setup)
Any other source	Console	Any	—	Deny

Inbound rules for the Database Server

Source	Destination	Port / Protocol	Purpose	Required
Console Server only	Database Server	TCP 5432 (PostgreSQL)	Console ↔ database	Yes
Administrators’ SSH clients (management network / VPN only)	Database Server	TCP 22 (SSH)	Server administration	Restricted
Any other source (including the internet)	Database Server	Any	—	Deny

The Database Server must not have a public IP address and must not be reachable from the internet, from Responders, or from user networks.

Notes

Assign static IP addresses to both servers.
If your firewall or load balancer performs TLS termination for port 443, re-encrypt to the Console (HTTPS to the backend) and make sure WebSocket connections are passed through, otherwise interACT will not work.
Port 4222 is optional for basic operation (Responders fall back to polling) but required for real-time task delivery and the best interACT experience.

Separating management access from Responder access

Enable the Console Port feature

AIR can serve the Console UI and API on a dedicated port (8443) while Responders continue to use 443. The setting is in Settings → Security → Console Port. Enabling it is recommended for every internet-facing Console.

When the Console Port feature is enabled:

Management traffic (UI, login, SSO, API, integrations) is expected on 8443.
Requests for management functions that arrive on the Responder port (443) are rejected by the Console. Only Responder-facing functions remain available on 443.
Login requests on the management port are rate-limited by the Console.

Combined with the inbound rules for the Console Server (8443 reachable only from VPN/office), this means no login to the Console is possible from the internet, regardless of how the load balancer is configured, because the separation is enforced by the Console itself.

Points to plan for:

Any integration that calls the Console — SSO identity provider callbacks, inbound webhooks, HTTP triggers, Git repository webhooks, public API clients — must use the management port (8443) and must therefore be reachable from where those integrations run.
Health checks from a load balancer or monitoring system must target GET /api/app/check, which remains available on the Responder port and is exempt from IP Restriction. Note that it only confirms that the Console process is up; it does not verify the database connection. Other health paths are rejected on 443 when the Console Port feature is enabled.

IP Restriction: when it works and when it does not

AIR’s IP Restriction (Settings → Security) limits which source addresses may use the Console UI and API. It applies to all management functions including the login page; it does not affect Responder communication.

The Console determines the source address from the connection it receives. This has a direct consequence for your topology:

Topology	In-product IP Restriction	Where to enforce the allowlist
Console directly reachable (no load balancer / proxy in front)	Works as intended	In the product, and/or at the firewall
Layer-4 load balancer that preserves the client source address (TCP passthrough with source IP preservation)	Works as intended	In the product, and/or at the load balancer
Layer-7 load balancer, reverse proxy or WAF in front of the Console	Does not work — the Console sees the proxy’s address for every request, so a rule either blocks everyone or allows everyone	At the load balancer / WAF / firewall only. Do not enable in-product IP Restriction in this topology

The same applies to any IP-based information the Console records: behind a layer-7 proxy, the addresses shown in audit logs and login history are the proxy’s address. Keep the access logs of your load balancer or WAF (which contain the real client address) for forensic purposes — see Monitoring, logging and detection.

Identity and account hygiene

Enforce two-factor authentication for all users (Settings → Security → Authentication), or configure Single Sign-On with your identity provider and enforce MFA and conditional access there. SSO overrides the in-product 2FA setting.
Apply least privilege with AIR’s role model: keep the number of global administrators to the minimum, use organisation-scoped roles for analysts, and review role assignments periodically.
Inventory API tokens, rotate them on a schedule, and remove tokens and user accounts that are no longer used.

Perimeter protection: WAF, load balancer and reverse proxy

Place a WAF in front of an internet-facing Console

If the Console’s HTTPS service is reachable from the internet on any port — 443 for Responders, or 8443 if you choose to expose the management port — put a web application firewall (or a reverse proxy with equivalent capabilities) in front of that listener and enable at minimum:

a managed core rule set (for example OWASP Core Rule Set) in blocking mode after a tuning period;
rate limiting and brute-force protection on authentication endpoints (/api/auth/*);
request normalisation before rule evaluation (URL-decode and lower-case the path) so that rules cannot be bypassed with alternative encodings;
request body size limits appropriate for your largest evidence uploads;
bot and scanner protection;
optionally, geographic or ASN restrictions if your Responders only connect from known regions.

Keep the WAF’s access logs (see Monitoring, logging and detection).

Load balancer configuration notes

Terminate TLS with a certificate from a trusted CA and re-encrypt to the Console.
The Console already sends an HTTP Strict Transport Security (HSTS) header. If your load balancer terminates TLS, make sure it preserves that header or sets its own on the public listener.
Pass WebSocket connections through (interACT).
Set idle timeouts high enough for long-running interACT sessions and large uploads.
Forward port 4222 as plain TCP (layer 4), not through the HTTP listener, and only from the networks your Responders connect from.
Log the client source address (for example via the X-Forwarded-For header) and retain the logs for at least 90 days.

Do not modify AIR’s own containers

Recommended WAF rules for AIR

The rules in this section are specific to AIR. They are written in vendor-neutral terms (what to match, what to do, how to verify) so that they can be applied on any WAF, load balancer or reverse proxy. Apply them in addition to the general measures above. Unless stated otherwise, each rule targets the internet-facing listener that serves Responders (port 443).

Rule 1: Block API documentation on the Responder listener (defence in depth, optional)

What it does: Blocks every request to the Console’s API documentation paths on the internet-facing (Responder) listener. Responders never use these paths, so the rule cannot affect Responder communication. The documentation remains available to your own users on the management port.

Match (apply after URL-decoding and lower-casing the path):

path starts with /api/swagger — covers /api/swagger.json, /api/swagger.yaml, /api/swagger.html, /api/swagger-v2.html
path equals /api/coverage.html
path starts with /api/v2/openapi
path starts with /swagger or equals /coverage.html (legacy addresses that redirect to the ones above)

Action: Block (HTTP 403). Scope: the listener that serves port 443. Do not apply it to the management port (8443) unless you do not use the API documentation at all.

Why: The documentation describes every API endpoint. It is protected by authentication today, and nothing that connects to the Responder listener needs it, so blocking it there costs you nothing. Doing so removes a fingerprinting target for internet-wide scanners and keeps the full API map out of reach even if the authentication layer is ever bypassed. When the Console Port feature is enabled, the Console itself already rejects these requests on 443; the rule is then a second, independent layer.

In plain terms: the “manual” of the API stays available to your own team on the management port, but nobody on the internet can read it.

Verify:

curl -s -o /dev/null -w '%{http_code}\n' https://<console-address>/api/swagger.json

Response	Meaning
`403` from your WAF	The rule is working
`403` with a Console error body mentioning the Console Port	The request reached the Console, which rejected it because the Console Port feature is enabled. The WAF rule is not applied, but the path is already closed on this listener
`401`	The request reached the Console; the rule is not applied (the Console still required authentication)
`000`	No HTTP response — usually a certificate trust problem on the test machine; retry with `-k`

To tell the two 403 cases apart, look at the response body (drop -o /dev/null): the Console returns a JSON error, your WAF returns its own block page or an empty body.

Rule 2: Block compressed request bodies (recommended)

What it does: Blocks any request to the Console that carries a Content-Encoding header. No AIR component — Responder, RelayPro, the Console UI or the Console’s internal services — compresses request bodies, so the rule has no functional impact on AIR. The Console, however, would decompress such bodies (gzip, deflate, Brotli, zstd) before processing them, which makes the decompression libraries reachable from the internet for no reason.

Match: request header Content-Encoding is present (any value).

Action: Block (HTTP 403). Scope: the Responder listener (443). Apply it to the management port (8443) as well unless your own API clients send compressed request bodies.

Why: Decompression code is a recurring source of memory-safety bugs, and vulnerabilities in it are fixed by runtime upgrades that self-hosted deployments do not always apply immediately. Blocking compressed request bodies removes the whole class of exposure rather than one instance of it, without affecting any AIR function.

In plain terms: AIR never sends compressed requests, so a compressed request can only come from something that is not AIR; rejecting it costs nothing and closes a door.

Verify (from outside your network):

curl -s -o /dev/null -w '%{http_code}\n' -X POST https://<console-address>/api/app/check -H 'Content-Encoding: gzip' -H 'Content-Type: application/json' -d '{}'

Response	Meaning
`403` from your WAF	The rule is working
Any other code (`400`, `404`, `405`, `415` …)	The request reached the Console; the rule is not applied
`000`	No HTTP response — certificate trust problem on the test machine; retry with `-k`

Repeat the test with the other encodings (deflate, br, zstd) if your WAF matches on specific values rather than on the presence of the header.

One thing to check first: the Responder has a local configuration option, supplied through the setup file at installation time, that adds custom request headers to its Console traffic. This is not a Console setting, and a standard deployment does not use it. If you have customised Responder installation files, make sure Content-Encoding is not defined there; otherwise your own Responders will be blocked by this rule.

Rule 3: Exclude AIR content paths from signature-based inspection (required when a managed rule set is in blocking mode)

Why: AIR legitimately transports content that looks like an attack to a signature-based rule set: YARA, Sigma and osquery rules, interACT shell commands, SQL queries in Investigation Hub, acquisition profile paths, multi-gigabyte evidence and log archives, and third-party JSON from SIEM/SOAR webhooks. A managed rule set (OWASP CRS or a vendor equivalent) in blocking mode will reject these requests and break the corresponding features.

Method: Run the managed rule set in detection/log-only mode for at least one normal operating cycle (including a triage with custom rules, an interACT session, an evidence upload and a PPC import). The WAF log from that period shows exactly which paths produce false positives in your deployment. Then create exceptions that skip signature inspection of the request body — and only that — for those paths. Keep rate limits, request size limits, authentication protections and bot controls active on those paths.

Do not exclude the authentication endpoints, /api/setup, /api/settings or /api/user-management from inspection; nothing legitimate there looks like an attack.

In plain terms: a WAF cannot tell a YARA rule or an interACT command from an attack, because they look the same; on these specific paths you tell the WAF to trust AIR’s own authentication instead of its signatures, while keeping every other protection in place.

Verify: After enabling blocking mode, repeat the operations from the tuning cycle and confirm that none of them is rejected. Check the WAF log for blocked requests originating from Responder addresses; each one is either a missing exception or a real problem on that asset.

Rule 4: Rate-limit authentication endpoints per client (required)

What it does: Limits how many requests a single client address may send to the login and password-recovery endpoints in a given time window, and temporarily blocks the address when the limit is exceeded.

Match: path starts with /api/auth/login, /api/auth/tfa/verify, /api/auth/tfa/recover, /api/auth/forgot-password, /api/auth/reset-password, /api/auth/recover-password-token or /api/auth/recover/. Do not apply the rule to other /api/auth paths; the Console UI calls them continuously.

Action: Allow at most 10 requests per minute per client address; on breach, respond with HTTP 429 and block the address for 15 minutes. Apply a separate, higher limit (for example 30 per minute) to /api/auth/sso/, or exempt it. If your analysts reach the Console through a shared NAT or VPN address, exempt that address or raise its limit. Use the client address as seen by your own perimeter device; never trust an X-Forwarded-For value that arrives from the internet. Scope: the listener that serves the Console UI (the management port when the Console Port feature is enabled, otherwise 443).

Why: The Console applies its own request limit to the authentication endpoints, but that limit is a general safeguard rather than a per-client brute-force control. A per-client limit at the perimeter slows down password guessing from a single source and keeps one source from affecting logins for everyone else. Responders never call these endpoints, so there is no functional impact.

In plain terms: an attacker who guesses passwords gets locked out after a handful of attempts, while your analysts, who log in a few times a day, never notice the rule.

Verify: From outside your network, send eleven login requests with a wrong password within one minute; the eleventh should be answered by the WAF with 429, and the address should stay blocked for the configured period.

Outbound (egress) control

The AIR Console Server and the Database Server should only be allowed to open outbound connections to the destinations listed in this section; every other outbound connection from these two servers should be blocked and logged (a “default-deny” egress policy). A blocked outbound attempt from the Console is a signal worth investigating.

Responders are a different case. They run on your endpoints, and this guide does not tell you how to filter those endpoints’ outbound traffic. Destinations Responders need to reach only lists the destinations that Responders must be able to reach so that AIR keeps working if your endpoint networks are filtered.

Egress rules: Console Server to Binalyze services

The source of every rule in this table is the AIR Console Server.

Destination	Port / Protocol	Purpose	Required
`license.binalyze.com`	TCP 443	Licence validation and usage reporting	Yes
`check.binalyze.com`	TCP 443	New version check	Yes
`one.binalyze.com`	TCP 443	Feature flags, usage statistics, licence (FIS) reporting, Microsoft 365 / HubSpot account authorisation, in-product feedback	Yes
`responder.cdn.binalyze.com`	TCP 443	MITRE ATT&CK ruleset updates, Responder exclusion list, user-agent list (Responders receive these from the Console)	Yes
`cdn.binalyze.com`	TCP 443	Installer and update artefacts (compose files, update scripts, offline packages), predefined interACT command snippets	Yes (offline deployments: maintenance windows only)
`api.binalyze.com`	TCP 443	RFC 3161 timestamping	Yes, if timestamping is used
`cr.binalyze.com`	TCP 443	Container registry for upgrades	Maintenance windows
`*.docker.com`	TCP 443	Container runtime images during upgrades	Maintenance windows
Database Server	TCP 5432	PostgreSQL (2-tier)	Yes
Your integrations (see the next table)	As listed		Per environment
Any other destination	Any	—	Deny

Egress rules: Console Server to your integrations

Every integration you enable in AIR needs its own allow rule. If a destination is missing, the corresponding feature will fail once egress filtering is in place. Fill in the table for your environment:

Integration	Typical destination	Port / Protocol
Evidence repository — Amazon S3 / S3-compatible, Azure Blob, Google Cloud Storage, Box (repository validation, Repository Explorer, disk image import)	Provider endpoint (regional or private endpoint where available)	TCP 443
Evidence repository — SFTP (validation, Repository Explorer, Console backup)	Your SFTP host	TCP 22
Evidence repository — FTPS (validation, Repository Explorer)	Your FTPS host	TCP 21 / 990
Evidence repository — SMB (Repository Explorer only; the Console does not validate SMB repositories)	Your file server	TCP 445
Single Sign-On	Identity provider	TCP 443
SMTP (password reset, notifications)	Mail relay	TCP 25 / 465 / 587
Notifications — Slack, Microsoft Teams, Mattermost	Provider or your Mattermost webhook endpoint	TCP 443
Webhooks / event subscriptions	Your webhook receivers	TCP 443 or as configured
Automation Hub — HTTP actions and SIEM actions	Your HTTP endpoints and syslog collector	As configured
Syslog / SIEM audit log streaming	Your collector	TCP/UDP 514 or custom
LDAP / Active Directory	Domain controllers	TCP/UDP 389 / 636
TAXII threat intelligence	TAXII server	TCP 443
Git repositories (rule sets) — GitHub, GitLab, Bitbucket, Azure DevOps	`github.com`, `api.github.com`, `codeload.github.com`; `gitlab.com` or your GitLab host; `api.bitbucket.org`; `dev.azure.com` — only the providers you use	TCP 443
osquery schema refresh	`api.github.com`, `raw.githubusercontent.com` — optional; a bundled schema is used when unreachable	TCP 443
Cloud account import / cloud forensics — AWS, Azure, GCP	Provider API endpoints (AWS regional service endpoints; `management.azure.com`; `*.googleapis.com`)	TCP 443
Microsoft 365 integration (Cloud and SaaS Platforms — connecting a Microsoft 365 tenant for cloud collections)	Authorisation through `one.binalyze.com` (see the previous table); token validation against `graph.microsoft.com`; the collection itself reaches Microsoft 365 service endpoints	TCP 443
AI Assistant (bring your own key)	`api.openai.com`	TCP 443

Destinations Responders need to reach

Responders upload collected evidence directly to the evidence repository; the Console is not in that data path. If outbound traffic from your endpoint networks is filtered, make sure Responders can reach the following:

Destination	Port / Protocol	Purpose
Console address (or the RelayPro address, if used)	TCP 443, TCP 4222	Responder communication, real-time task delivery, interACT
The evidence repositories you use — Amazon S3 / S3-compatible, Azure Blob, Google Cloud Storage, Box	TCP 443	Evidence upload
SFTP repository host	TCP 22	Evidence upload
FTPS repository host	TCP 21 / 990	Evidence upload
SMB file server	TCP 445	Evidence upload
`oauth2.googleapis.com`	TCP 443	Only with Google Cloud Storage repositories (token exchange)

In a self-hosted deployment Responders obtain their update packages, rule sets and exclusion lists from the Console; they do not need to reach Binalyze content delivery hosts.

Egress rules: Database Server

The source of every rule in this table is the AIR Database Server.

Destination	Port / Protocol	Purpose	Required
`cr.binalyze.com`, `cdn.binalyze.com`, `*.docker.com`	TCP 443	Upgrades only	Open during maintenance windows, otherwise closed
Any other destination	Any	—	Deny

In-product Outbound Connection Allowlist

Independently of your firewall, the Console enforces an Outbound Connection Allowlist for private destination addresses (used by SFTP/FTPS repositories, SMTP, LDAP, syslog and proxy hosts). Configure it to the exact private subnets the Console needs, or set it to none if the Console needs no private destinations at all. This limits what the Console can reach inside your network. The policy is managed with the AIR CLI on the Console host (air-cli outbound-cidr); loopback, link-local and cloud metadata addresses are always blocked. See Outbound Connection Allowlist for the policy behaviour, the CLI commands and the configuration method for earlier versions.

Note that this feature governs private addresses only; public internet destinations are not restricted by it. It complements, but does not replace, the egress firewall rules above.

DNS and outbound proxy

Point the Console and Database Servers at an internal DNS resolver that logs queries, and make sure you can sinkhole a domain quickly. Blocking a destination at DNS is often the fastest containment step during an incident.
If the Console uses an outbound proxy (Settings → General → Console Proxy), apply the allowlist on the proxy as well, give the proxy account the least privilege possible, and include its credentials in your rotation schedule.

Data and credential protection

Encrypt evidence at acquisition

Enable Encrypt Evidence in your policies (or when starting a task). Collections are then stored as AES-256 encrypted archives, so if evidence repository credentials are ever exposed, or the storage itself is accessed directly, the collections remain unreadable. Keep the password in your password manager.

TLS on the Console

Use a certificate issued by a trusted certificate authority on the Console (and on the load balancer, if one terminates TLS). If you use a private CA, its root certificate must be trusted on every browser and on every asset running a Responder; otherwise Responders cannot register. Plan certificate renewal before expiry.

Evidence repository accounts

Create a dedicated account per repository with the least privilege the repository type needs: access only to the intended bucket, container or share, no permission to list or access other storage, and no delete permission unless your retention process requires it.
Rotate repository credentials on a schedule, and immediately after any suspected exposure.
Enable access logging on the storage side so that you can see which addresses used the credentials and when. This is the only way to determine, after the fact, whether a credential was used from outside the Console.
Where the storage platform supports it, restrict the account to connections originating from the Console’s egress address.

Monitoring, logging and detection

Forward audit logs to your SIEM

The Console keeps audit logs for three months. Enable Syslog / SIEM integration (Settings → Features) to stream audit events in CEF format to your log platform, and keep them for as long as your incident response process requires.

Alert on security-relevant events

Suggested detections, based on audit events and perimeter logs:

Event	Why it matters
A user, role or global administrator is created or changed	Privilege changes
An API token is created	New programmatic access
An evidence repository is added, edited or validated	Credentials are in motion
A series of failed logins, or a login from a new source address (from load balancer / WAF logs)	Credential attacks; note that behind a layer-7 proxy only the perimeter logs contain the real address

Keep perimeter logs

Retain load balancer and WAF access logs for at least 90 days. Intrusions are often identified days or weeks after they happen; with shorter retention, the entry point may no longer be visible when you need it.

Test your external surface

Scan your public Console address regularly with an external vulnerability scanner.
Verify from outside your network that a login attempt on port 443 is rejected when the Console Port feature is enabled, and that port 8443 is not reachable at all.
Assume that an internet-facing Console can be found by internet-wide scanning services; the controls in this guide are what limit what such a scan can do.