Skip to main content
Aviatrix Controller 8.2 introduces Intrusion Prevention System (IPS) capabilities, extending beyond detection to active enforcement. IPS operates inline on the data path, enabling real-time threat prevention for workloads across multicloud environments. Controller 8.2 introduces the following IPS capabilities:
  • Feature: IPS with inline enforcement
  • Profiles: Default and custom IPS Profiles supported
  • Custom Rulesets: Suricata-based, external feed integration
  • Automation: Full Terraform and API support
  • UI Update: IPS configuration under DCF

​
Key Features

  • Drop Traffic on Signature Match: IPS enforces inline live traffic for immediate protection
  • IPS Profiles: Define actions per signature severity (alert or drop). Built-in Default IPS Profile or custom profiles with user-defined rule feeds and signature ignoring
  • Custom Suricata Rulesets: Apply custom Suricata rule feeds for rapid response to emerging threats
  • DCF Policy-Driven Inspection: DCF Policy determines which traffic is inspected by IPS
  • Terraform and API Support: Full automation for IPS configuration and profile management

​
IPS Benefits

  • Immediate Enforcement: IPS works inline on the data path for real-time protection
  • Granular Control: Ignore or customize signatures as needed
  • Custom Rulesets: Rapid response to emerging threats; tailor rules for unique environments
  • Compliance and Security Posture: Meets enterprise requirements for proactive threat prevention
  • Reduced Risk: Stops malicious traffic instantly
  • Operational Agility: Quick adaptation to new threats
  • Enterprise Readiness: Scalable, customizable security for multicloud environments

​
IPS Enforcement Flow

  1. Traffic Selection: DCF policy determines which flows are inspected
  2. Signature Matching: IPS evaluates traffic against Suricata rules
  3. Action Execution: Alert only (IDS mode) or Drop traffic (IPS mode)
  4. Logging and Reporting: Events logged with severity, signature ID, and action

​
Configure IPS

​
Configure IPS on Aviatrix CoPilot

To configure IPS on Aviatrix CoPilot, follow these steps:
  1. Go to Security > Distributed Cloud Firewall > IPS.
  2. Review the Default IPS Profile or create a Custom IPS Profile: Define drop actions based on the Severity levels of the Suricata rules. For example, if Major and higher is selected, any traffic that IPS inspects and triggers a Major or Critical severity level will be dropped.
  3. (Optional) Upload Custom Suricata Ruleset. Note: Refer to https://sidallocation.org/ for recommended signature ranges. “Local” signature rules should be in the range of 1000000-1999999 to avoid conflicts with well-known feeds.
    On decrypted traffic, the Emerging Threats rule SID 2013933 (ET POLICY HTTP traffic on port 443 (CONNECT)) is broad in scope and will match a wide range of HTTP-over-443 flows. If you rely on more specific custom rules to evaluate the same decrypted flows, place those rules in your custom ruleset so they are loaded alongside the default feed; both rules are evaluated, and the action of the most severe matching rule is applied per the IPS Profile severity threshold.
  4. Activate the IPS Profile so that it applies globally.
  5. Turn on Intrusion analysis and TLS decryption (for DPI) in DCF policy.
  6. You can validate the enforcement via CoPilot > Security > Distributed Cloud Firewall > Monitor > Intrusion Logs

​
Configure IPS Using Terraform

The following example demonstrates how to configure IPS using Terraform.

​
Upload a Custom IPS Rule Feed

​
Severity Requirement for Custom Rules

IPS decides whether to drop matching traffic based on the severity that a signature declares, not the action written in the rule header. A custom rule that does not declare a valid severity generates alerts but never drops traffic, regardless of the Drop Level configured on the IPS Profile.
Always add a valid severity to every custom rule you intend to enforce. A rule without one silently never drops traffic, even at the most aggressive Drop Level, and IPS gives you no warning when this happens: the rule feed upload succeeds, and alerts appear normally under Monitor > Intrusion Logs.

​
Why Severity Is Required

When traffic matches a signature, IPS checks the following conditions in order and stops at the first one that applies:
  1. The SID is on the Ignored SIDs list for the active IPS Profile. IPS suppresses the match entirely: no alert, no drop.
  2. The SID is on the Alert Only SIDs list for the active IPS Profile. IPS raises an alert but never drops the traffic. This takes precedence over the Drop Level.
  3. The signature declares a severity that the Drop Level covers. IPS applies the configured action, either alert only or alert and drop.
  4. The signature declares no severity, or a severity value IPS does not recognize. IPS raises an alert and allows the traffic through.
A rule with no severity, or with a severity value IPS does not recognize, always reaches condition 4. Because there is no Drop Level setting that matches an unrecognized severity, a rule in this state can never reach a drop decision.

​
Add the Required Metadata

Declare severity in the rule’s metadata keyword:
Accepted values are case-sensitive and must match exactly: Any other value is not recognized and leaves the rule alert only. This includes lowercase variants such as major, and other vocabularies such as High or Medium. Severity can appear alongside other metadata entries, in any order:

​
Examples

This rule declares Critical severity, so IPS drops the traffic whenever the active IPS Profile’s Drop Level covers Critical severity:
This rule has no metadata keyword at all, so it alerts but never drops:
This rule declares a severity, but the lowercase value is not recognized, so it also alerts but never drops:

​
Recognize a Rule That Cannot Drop Traffic

Because a missing or unrecognized severity produces no error, use the following differences to recognize the condition: If a signature appears correctly under Monitor > Intrusion Logs but never appears in the Policy Logs and is never dropped, even at the most aggressive Drop Level, the rule is missing a valid severity declaration.
Writing drop instead of alert in the rule header has no effect on enforcement. IPS derives the drop decision entirely from the signature’s severity and the SID exception lists on the active IPS Profile; the action in the rule header is not consulted. Write custom rules with alert and control enforcement through the IPS Profile’s Drop Level and SID exceptions. The system default IPS Profile itself does not drop any traffic; it ships with every severity level set to alert only. To enforce drops, activate an IPS Profile that sets a Drop Level covering the severities you want to enforce.