> ## Documentation Index
> Fetch the complete documentation index at: https://docs.aviatrix.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Platform Security Hardening Guidelines
> Secure the Aviatrix platform by hardening controllers, gateways, and CoPilot instances. Covers public IP mitigation, egress controls, WAF deployment, authentication, and a shared responsibility matrix.
This document explains how the Aviatrix platform is secured and how you can
harden your deployment to meet security architecture board and compliance
reviews. It covers public IP usage, egress controls, cloud-specific security
techniques, and recommended configurations for Controllers, Gateways, and
CoPilot.
This document does not cover Product Security Assessments, Information
Security Policy, Compliance Standards, vulnerability assessments, penetration
testing, or source code review. Those materials are available separately under
NDA.
## Recommended Hardening Actions
The following checklist summarizes the actions you should take to reach a fully
hardened deployment:
* **Restrict Controller/CoPilot inbound access.** Limit TCP/443 to corporate VPN
or WAF source CIDRs instead of the default internet-open security group. See
[Reduce Surface Area](#reduce-surface-area).
* **Deploy a WAF in front of the Controller.** Use AWS WAF, Azure App Gateway
WAF, or GCP Cloud Armor. See [Reduce Surface Area](#reduce-surface-area).
* **Replace the self-signed certificate.** Import a corporate CA-issued
certificate. See [Use Signed Certificates](#use-signed-certificates).
* **Remove less secure TLS versions.** Only support TLSv1.2 and above. See
[Remove Less Secure Versions of TLS](#remove-less-secure-versions-of-tls).
* **Federate authentication via SAML or LDAP.** Integrate with your identity
provider and enable 2FA. See
[User Authentication to Controllers](#user-authentication-to-controllers).
* **Harden password policy.** Tune password length, complexity, and expiration
to corporate standards. See
[Harden Password Requirements](#harden-password-requirements).
* **Lock down egress security groups.** Use the
[Outbound Connection Tables](#outbound-connection-tables) to allow-list only
required destinations for Controllers, Gateways, and CoPilot.
* **Add defense-in-depth for Gateways.** Layer NACLs (AWS) or subnet-level NSGs
(Azure) on top of the default security groups. See
[Azure Gateway Security Controls](#azure-gateway-security-controls) and
[AWS Gateway Security Controls](#aws-gateway-security-controls).
* **Enable Gateway Subnet Monitoring (AWS).** Prevent unauthorized instances in
Gateway subnets. See
[Monitor Gateway Subnet](#monitor-gateway-subnet-controller-feature).
* **Deploy Controller HA.** Use the provided HA templates and verify recovery.
See
[Controller High Availability in AWS and Azure](#controller-high-availability-in-aws-and-azure).
* **Configure CoPilot SAML and least-privilege service accounts.** Avoid
`all_write`; use feature-scoped permission groups. See
[Securing CoPilot](#securing-copilot).
* **Keep software up to date.** Subscribe to PSIRT advisories and apply patches
per your cadence. See
[Post-Release Vulnerability and Patch Management](#post-release-vulnerability-and-patch-management).
For the full responsibility breakdown, see the
[Shared Responsibility Matrix](#shared-responsibility-matrix) at the end of this
document.
## Background
The Aviatrix Controller and Gateway communicate over a management/control plane
channel that uses public IP addresses. This secure channel is established during
Gateway creation and handles:
* Gateway health checks
* Route and policy updates from the Controller
* Gateway statistics
* Keepalives in both directions
* Diagnostic requests from the Controller
Public IP addresses ensure connectivity between the Gateway and the Controller
regardless of geographic or CSP location.
In addition to the management/control plane channel, Gateways initiate sessions
to the internet for Linux package updates, Gateway log uploads, and other
operational tasks. You can obtain a comprehensive list of known Gateway
activities and their corresponding ports and protocols from Aviatrix, then lock
down the outbound security group to only allow permitted activities.
## Outbound Connection Tables
The following tables list outbound connections initiated by each Aviatrix
component. Use them to configure egress security groups.
### Spoke and Transit Gateway Outbound
| Outbound | Port | Purpose | Plane | Mitigation |
| ------------------------------------------------------------------------- | ----------------- | ------------------------------ | ---------- | --------------------- |
| Controller | 443 TCP | Keep alive, reverse SSH, SPIRE | Management | Egress security group |
| CoPilot | 5000 UDP | Syslog | Management | Egress security group |
| CoPilot | 31284 TCP | OTEL | Management | Egress security group |
| CoPilot | 31283 UDP | NetFlow | Management | Egress security group |
| DNS Server | 53 UDP | DNS resolution | Management | Egress security group |
| Aviatrix Services (\*.aviatrix.com) | 443 TCP | Telemetry | Management | Egress security group |
| Other Transit/Spoke Gateways | UDP 500, UDP 4500 | IPSec auth and data channel | Data | Egress security group |
| Datadog (datadoghq.com, datadoghq.eu, ddog-gov.com, \*.us3.datadoghq.com) | TCP 443 | System metrics | Management | Egress security group |
| OS updates (\_.ubuntu.com, \_.debian.org) | TCP 443 | Updates | Management | Egress security group |
### Controller Outbound
| Outbound | Port | Purpose | Plane | Mitigation |
| ------------------------------------------------------------------------- | ------------- | ---------------------------------- | ---------- | --------------------- |
| DNS Server | 53 UDP | DNS resolution | Management | Egress security group |
| NTP Server | 123 UDP | Sync system time | Management | Egress security group |
| Aviatrix Services (\*.aviatrix.com) | 443 TCP | Registry, updates, telemetry | Management | Egress security group |
| CoPilot | 5000 UDP | Syslog | Management | Egress security group |
| AWS CSP APIs (\*.amazonaws.com) | 443 TCP | AWS APIs | Management | Egress security group |
| GCP CSP APIs (\*.googleapis.com) | 443 TCP | GCP APIs | Management | Egress security group |
| Oracle CSP APIs (\*.oraclecloud.com) | 443 TCP | Oracle APIs | Management | Egress security group |
| Azure CSP APIs | 443 TCP | Azure APIs | Management | Egress security group |
| Other Transit/Spoke Gateways | 443 TCP | GW state, policy control, upgrades | Management | Egress security group |
| Sendgrid (smtp.sendgrid.net) | 2525, 587 TCP | SMTP emails | Management | Egress security group |
| Duo (\*.duosecurity.com) | 443 TCP | Duo login integration | Management | Egress security group |
| Other Services (\_.debian.org, \_.ubuntu.com) | 443 TCP | Package upgrades | Management | Egress security group |
| Datadog (datadoghq.com, datadoghq.eu, ddog-gov.com, \*.us3.datadoghq.com) | TCP 443 | System metrics | Management | Egress security group |
### CoPilot Outbound
| Outbound | Port | Purpose | Plane | Mitigation |
| ------------------------------------------------------------------------------------ | ------- | ----------------------------------------------- | ---------- | --------------------- |
| Controller | 443 TCP | Communication with Controller | Control | Egress security group |
| DNS Server | 53 UDP | DNS resolution | Management | Egress security group |
| Aviatrix Services (\*.aviatrix.com) | 443 TCP | Telemetry, security, diagnostics | Management | Egress security group |
| NTP Server | 123 UDP | Sync system time | Management | Egress security group |
| Other Services (\_.elastic.co, \_.googleapis.com, \*.ubuntu.com, deb.nodesource.com) | 443 TCP | GeoIP service, storage bucket, package upgrades | Management | Egress security group |
## Gateway Deployment
The Aviatrix Controller leverages CSP APIs to deploy Gateways into VPCs and
VNETs. During deployment, the management/control plane channel is created.
* The Controller pushes the necessary software packages and begins
bi-directional communication.
* The Controller updates the security group of the instance to only allow
TCP/443 from the Controller public IP address, ensuring only the Controller
can reach the Gateway over its public IP.
* IP Forwarding is enabled on the Gateway instance for packet forwarding.
The following illustration shows the location of the Gateways within the target
state architecture in a hub and spoke design.
## Azure Spoke Design Options
Aviatrix supports two spoke design options in Azure: with and without Spoke
Gateways.
| Feature | Without Spoke Gateways | With Spoke Gateways |
| ------------------------------ | ---------------------- | ------------------- |
| Dataplane Encryption | No | Yes |
| NAT Support | No | Yes |
| Instance Visibility in CoPilot | No | Yes |
| VNET Latency Monitoring | No | Yes |
| Multi-Cloud Segmentation | Yes | Yes |
| Dynamic Control Plane | Yes | Yes |
| UDR Programming | Yes | Yes |
Choose between these options based on your spoke requirements. Each option has
tradeoffs in terms of feature availability and deployment complexity.
## Azure Gateway Security Controls
Aviatrix has compiled several techniques and best practices for securing public
IP usage in Azure. These techniques are designed to be layered within your
environment to maximize security.
### Azure Management Groups
Azure management groups allow you to group multiple subscriptions and apply
policy at the management group level. Work with Aviatrix to fine-tune Azure
policy and simplify policy management within your Azure environment.
### Azure Subnet Level Security Group
Azure offers network security groups (NSGs) at the vNIC level and at the subnet
level for instance egress protection. You can apply NSGs at the subnet level to
specify permitted public IPs for allowing internet egress. NSGs at the vNIC
level and the subnet level are combined when determining policy enforcement, and
a deny policy at the subnet level blocks the communication regardless of the NSG
at the vNIC level.
Example NSG rules at the subnet level within the VNET:
* Aviatrix Gateway public IP a.a.a.a is permitted to go to the internet gateway
* Aviatrix Gateway public IP b.b.b.b is permitted to go to the internet gateway
* All other public IPs are denied to go to the internet gateway
You can also leverage NSGs at the vNIC level on the Aviatrix Gateway and use
tags to exempt them from the public IP policy. The Aviatrix Controller tags all
Aviatrix Gateway instances with "Aviatrix-Created-Resource". This ensures that
virtual machines within a VNET that do not have an Aviatrix tag are not exempt
from the policy.
## AWS Gateway Security Controls
Aviatrix has developed features on the Controller and different AWS techniques
that allow the use of public IP addresses on Gateways but do not allow any other
internet connectivity.
### Monitor Gateway Subnet (Controller Feature)
For Aviatrix Spoke Gateways deployed in AWS, the Controller has a built-in
feature called **Monitor Gateway Subnets**. This feature tells the Controller to
monitor the subnet where the Gateways are deployed, and if another instance is
deployed within that subnet, shut it down.
This feature allows you to create a single public subnet in two different AZs
within an AWS VPC that are used only for the Aviatrix Gateways. All other
subnets within the VPC are private, which prevents instances from reaching
internet resources out of the IGW.
Within this architecture there are private and public subnets and two
corresponding route tables. The private RT contains routes programmed by the
Controller to send traffic to the Gateways within the VPC. The public RT has a
default route to the IGW, and only the subnets with the Aviatrix Gateways use
this RT.
### AWS Security Groups
For Aviatrix Gateways deployed in AWS, a security group is created along with
the instance and applied to the ENI of the Gateway. By default, the security
group has restricted access to only the Controller public IP address on TCP/443.
### AWS Access Control Lists
For Aviatrix Gateways deployed in AWS, you can use a network access control list
(ACL) in addition to the security group to further restrict public access.
## Post-Release Vulnerability and Patch Management
* Make ongoing plans for periodic updates to the latest image and software
versions.
* For critical security vulnerabilities such as zero-day exploits,
pre-authentication flaws, or remote code execution, Aviatrix releases a hotfix
or security patch within industry-standard SLAs. The Aviatrix Product Security
Incident Response Team (PSIRT) provides guidance on implementing compensating
controls where applicable.
* Aviatrix continuously leverages multiple industry-leading vulnerability
scanning tools to identify CVEs and detect potentially malicious third-party
dependencies. All findings are reviewed by the Product Security team to assess
impact and prioritize remediation.
* For each vulnerability, the Aviatrix PSIRT determines whether there is any
risk to the Confidentiality, Integrity, or Availability (CIA) of the overall
architecture. If there is any risk, the PSIRT Incident Response Process
begins.
### Software Architecture
* Aviatrix software runs on a standard Ubuntu Linux operating system that is
closed, locked down, and hardened to CIS hardening standards.
### Deployment Security
* Aviatrix Enterprise deployment operates within your environment. Aviatrix has
no access to your data.
* If you need Aviatrix Customer Support to assist in resolution of an issue,
initiate this through the dedicated customer support functionality in the
product. You can terminate this access at any time.
### Configuration Hardening
* All Aviatrix Controller commands at the console or REST API and events are
logged to rsyslog.
* All Aviatrix Gateway events are logged to rsyslog.
* SSH access to Controller, CoPilot and Gateway instances is restricted and not
exposed by default. If port 22 is manually enabled for troubleshooting
purposes, it is the customer's responsibility to limit access to trusted
source CIDRs.
* The Controller web interface (tcp/443) is, by default, available to the
internet. Use security groups to limit access to the Controller to known
internal IP addresses.
* Images are hardened to CIS Server Level 1.
### Software Update Security
* Software is only updated from the Aviatrix software repository server when you
request a specific command at the Aviatrix Controller.
* All communication between you and the Aviatrix Controller is protected through
TLS.
## Securing the Aviatrix Controller
### Enable Additional Controls to Access Controller
#### Reduce Surface Area
* Only allow TCP/443 from the most limited inbound IPs or CIDR blocks as
possible. By default this is open to the internet; reduce this in the CSP
Security Groups.
* Restrict access to the Controller UI to the corporate VPN. If you use Aviatrix
VPN, you can whitelist user IPs to allow VPN clients to reach the Controller
UI.
* Deploy a WAF in front of the Controller UI to provide additional
application-layer protection and enforce strict access policies.
* Gateways must have a public IP and their security group must be restricted to
the public IP address of the Controller.
* Use a load balancer and/or WAF in front of the Controller. In Azure, use WAF
with Azure Managed rules on Application Gateway to limit usual web attacks
against the Controller.
In GCP, an HTTPS load balancer can be used in a similar manner to secure the
Controller.
In AWS, use WAF with AWS Managed rules on ALBs to limit usual web attacks
against the Controller.
### Automatic Security Group Management
* This feature automatically manages the Controller instance inbound rules from
the Gateways.
* When enabled, the Controller immediately creates security groups and allows
only specific Aviatrix Gateway to Controller communication.
* Edit the security rules that are outside the Gateway public IP address to
limit the source address range.
### Use Signed Certificates
* Aviatrix Controller ships with a self-signed certificate which provides
browser warnings for an insecure site (Untrusted Certificate).
* Replace the self-signed certificate by generating a CSR and importing a
certificate, or by importing a certificate with key.
### Remove Less Secure Versions of TLS
* Only support TLSv1.2 and above.
* Disable access from browsers that support TLSv1.0 or TLSv1.1.
## User Authentication to Controllers
The Controller supports a variety of options for user login. Integrate into your
identity platform such as Active Directory, LDAP, or SAML providers. If username
and password are required, harden the password requirements and enable 2FA.
### Enable LDAP Integration for Controller Login
* Replace standard username/password of local accounts with corporate directory
access.
* Navigate to **Settings** > **Controller** > **LDAP Login**.
### Enable SAML Login
* Instructions:
CoPilot SAML Authentication
### Harden Password Requirements
* Navigate to **Settings** > **Advanced** > **Password Management**.
* Change minimum and maximum password length.
* Reflect corporate password requirements for upper/lower-case, numeric, and
special characters.
* Define the maximum number of days the password is valid.
* Define the number of passwords in the Password History.
* Aviatrix Password Management Documentation
### Enable Duo 2FA
* Use Duo authentication if relying on username/password authentication.
* Navigate to **Settings** > **Controller** > **2FA**.
* Aviatrix Duo 2FA Authentication Documentation
### Use Role-Based Access Controls (RBAC)
* Create capabilities in the application required for different role personas to
complete their job responsibilities.
* RBAC limits attack surface area and reduces the potential for catastrophic
errors by reducing the operations a specific user can perform.
* If an account is compromised, the attacker only has access to those
capabilities, not the full capabilities of the entire system.
### Encrypt EBS Volumes
* Ensure that all non-ephemeral storage is encrypted using CSP-provided
capabilities such as AWS EBS volume encryption.
## Securing Gateways
### Public Subnet Requirements
* Use security best practices to only open connectivity to the Gateway from an
approved allow list.
* While deploying transit solutions, CSPs require vendor Gateways to be deployed
on public subnets.
* Aviatrix Transit Gateways in the Transit VPC/vNET establish secure IPSEC
tunnels with Spoke VPCs over public IP whether the Spoke VPC/vNET deployed a
vendor Gateway or VGW.
* Although the connectivity patterns leverage public IPs, the path never hits
public internet and is routed within the CSP backbone.
* When the Controller communicates with Gateways or Gateways communicate across
Cloud Provider boundaries, this communication is secured at the application
layer or uses IPSec as needed.
### Securing Public Subnets
* Enable **Gateway Subnet Monitoring**.
* When enabled, the Aviatrix Controller monitors selected public subnets
periodically.
* When it detects any instances launched on these subnets, the Controller alerts
the admin and stops the instances.
### Gateway Security Groups and Ports
* The Aviatrix Gateway instance has strict security group allowances that are
only open to the Controller IP on tcp/443 (https).
* tcp/443 (https) for upgrades from the Controller and diagnostic purposes.
### Gateway to Gateway IPSec
* Gateway to Gateway IPSec tunnels require two incoming ports:
* udp/4500 (Data Channel for IPSec NAT Traversal)
* udp/500 (Control Traffic for IPSec - ISAKMP)
## Securing CoPilot
### Associate Controller with Your CoPilot
Enable the Controller to manage CoPilot Security Groups:
1. Navigate to **Settings** > **CoPilot** > **CoPilot Security Group
Management**.
2. UDP port 5000 - Enable syslog for CoPilot Egress and Audit Data from each
Gateway. Gateways send remote syslog data to CoPilot.
3. TCP port 31284 - Enable logs for CoPilot Egress and Audit Data from each
Gateway. Gateways send remote logs data to CoPilot.
4. TCP port 5000 (default) - Private Mode Only - Enable Syslog for CoPilot
Egress FQDN and Audit Data (from each Gateway). Gateways send remote syslog
to CoPilot.
5. UDP port 31283 (default, configurable) - Enable Netflow for CoPilot FlowIQ
Data (from each Gateway). Gateways send Netflow data to CoPilot.
### Configure SAML
Enhance the login protections to your CoPilot instance using the corporate
Identity Provider. See
Set Up SAML Login for CoPilot
.
Additionally, by using the Identity Provider, you can ensure that employees who
no longer have access to CoPilot are revoked the moment they are revoked from
the Identity Provider. Using username/password requires manual intervention from
the corporate IT team or other team managing access to CoPilot.
### CoPilot Service Accounts
All CoPilot installations require Service Accounts to perform operations with
other components of the Aviatrix System. Some of these permissions must be
created by the CoPilot system administrator to have minimal permissions to the
features:
* CoPilot ThreatIQ and Distributed Firewalling require CoPilot service to have
minimum `all_firewall_network_write` (Firewall Network permission group)
permissions.
* CoPilot Gateway Scanning requires `all_gateway_write` (Gateway permission
group) permissions.
Full Access can be provided to the service accounts using the `all_write`
(AllWrite permission group), however, this is not best practice as it gives a
service account more permissions than needed and does not comply with the
principle of least privilege.
## Controller High Availability in AWS and Azure
### AWS
Aviatrix Controller and CoPilot HA in AWS leverages Auto Scaling Groups (ASGs),
Elastic Container Service (ECS), and supporting AWS services to provide high
availability and seamless recovery. The Controller and CoPilot each run in their
own ASG. When a new instance is launched, it is initialized to the specified
version (latest by default), and Controller backups are configured
automatically. An AWS load balancer is configured with both the Controller and
CoPilot instances as targets to provide continuous availability.
ECS handles Controller and CoPilot failover events. When an ASG event occurs, an
Amazon EventBridge rule triggers ECS. ECS then restores the configuration from
the latest backup on the new instance, ensuring minimal downtime. Supporting
services such as Amazon SNS and SQS integrate with this workflow: ASG events are
published to SNS, and the subscribed SQS queue delivers messages to ECS,
enabling it to take the appropriate recovery actions.
This design ensures that new Controller or CoPilot instances are automatically
initialized, configured, and restored whenever a failover event occurs,
maintaining availability across Availability Zones.
A Controller can be manually launched from a different region and the backed-up
configuration can be restored on it. The Controller new EIP should not cause any
issues unless SAML VPN authentication is being used. (All peering tunnels will
still work). In that case, SAML VPN client will need to reach the Controller IP
address. If the FQDN hostname is used for the Controller for SAML, then it
should work after changing the Route 53 to resolve to the correct EIP in the
different region.
### Azure
A similar Controller HA design is available in Azure using scale set and load
balancer. This solution uses Azure function to manage failover events along with
periodic backup if needed.
## Shared Responsibility Matrix
The matrix below summarizes which security controls Aviatrix already enforces in
the product versus the controls you are expected to configure or maintain. Use
this as the audit reference when answering an architecture review board.
| # | Security Control | Aviatrix Default Behavior | User Action |
| -- | -------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| 1 | OS hardening (CIS) | Hardened system against CIS hardening standards | None |
| 2 | Controller/CoPilot inbound TCP/443 | Open to internet by default in the auto-created SG | Restrict to corporate / VPN / WAF source CIDRs |
| 3 | Self-signed Controller certificate | Self-signed certificate | Replace with a corporate CA-issued certificate |
| 4 | Cloud-managed WAF in front of Controller | Not deployed by Aviatrix | Deploy AWS WAF, Azure App Gateway WAF, or GCP Cloud Armor and route Controller traffic through it |
| 5 | Local-account password policy | Configurable; defaults 8 characters, with one uppercase letter, one number, and one special character | Tune to corporate standard |
| 6 | Multi-factor authentication | Duo integration available | Enable Duo for any local accounts; for richer MFA, federate via SAML and let the IdP enforce MFA |
| 7 | Gateway inbound SG / NSG | Restricted to TCP/443 from the Controller IP only | Add stateless NACL layer (AWS) or subnet-level NSG (Azure) for defense in depth |
| 8 | Gateway-to-Controller mTLS | Identity-based mTLS | None |
| 9 | Gateway data-plane encryption | AES-256-GCM IPsec by default | None |
| 10 | Patch management policy | PSIRT publishes advisories; no auto-pull; software updated only on user-initiated upgrade | Subscribe to advisories; apply per cadence; verify running version after upgrade |
| 11 | Controller HA on AWS/GCP/Azure | CloudFormation template provided | Deploy the HA template; verify recovery in a controlled drill |
| 12 | Egress allow-listing for Aviatrix outbound traffic | Aviatrix-hosted, third-party, and cloud-provider destinations are documented in the Egress Allow-list table | Refer to previous connection tables and enforce the listed destinations in cloud security groups, NSGs, firewall rules, or forward proxy as the outbound allow-list for the Controller, Gateway, and CoPilot |
| 13 | CoPilot service accounts (RBAC) | Permission groups available | Use feature-scoped permission groups (all\_gateway\_write, all\_firewall\_network\_write, all\_security\_write, etc.); avoid all\_write for integrations |
| 14 | CoPilot/Controller SAML federation | Available | Configure SAML integration with the Identity Provider (IdP) |