About Rules
Rules enable communication between multiple applications or entities across different scopes or within the same scope.
Illumio supports the delegation of rule writing using role-based access control (RBAC). Application administrators can only edit rules where the policy's scope matches the scopes for which they have administrator privileges. They cannot create or manage policies if the scope includes “All.”
Rule types enable the application administrator to create rules that allow other applications to communicate with the managed applications without requiring global administrator privileges. This feature enables users to group rules required for inter-application and intra-application communication within a specific application into a single policy.
You can combine multiple types of rules (intra-scope, extra-scope, and custom iptables) in a single policy.
You can use multiple services, ports, and protocols in a rule. This approach helps reduce the number of rules in your PCEs, thereby improving PCE performance.
Note
You cannot provision drop actions from the PCE in a NAT table for custom IP tables. Doing so results in a firewall generation failure.
Types of Rules
Rules are created based on application groups, which define the scope of the rules.
To write a rule, you need to define three things: A service, a source of the service, and a destination of the service. You also need to select the type of rule:
Intra-scope rule: Allow communication within a group.
Extra-scope rules: Allow communication between groups.
Custom iptables rules: Allows custom iptables configurations in a policy. These rules are managed by the PCE and applied on each managed Linux workload VEN that matches the labels for the scope and receivers.
Intra-scope Rules
Note
The ability to create intra-scope rules is only enabled when the PCE is configured to display it.
Intra-scope rules enable authorized users to create rules that facilitate communication between sources and destinations within a specific scope. This rule type is typically used to allow communication between workloads that belong to the same application. For intra-scope rules, the labels used in the scope must match the labels used for both the source and the destination. If you don't specify a Label, “All” is used by default.
For example, you can create a rule allowing all Database workloads with the labels HRM | US | Dev to accept MySQL connections from all Web workloads with the same labels.
For intra-scope rules, both source and destination labels must match the labels defined in the scope.
Extra-scope Rules
Note
The ability to create extra-scope rules is only enabled when the PCE is configured to display it.
Extra-scope rules are created for communications coming from outside the scope.
Extra-scope rules enable authorized users to create rules that facilitate communication between the scoped application and external entities. Specifically, you can write rules that enable Sources within a scope to be accessed by Destinations in or outside the specified scope. For extra-scope rules, the labels used in the scope must match the labels used by the source. If you don't specify a label, “All” is used by default.
Label Matching: Destination labels must match those used in the scope, while source labels can be outside. For example, use "All Workloads" and "All Services" between application groups to learn about the roles and services that must be allowed without prematurely restricting communications.
Once you know the exact services and workload roles, switch to "Specific Workloads" and "Specific Services" to tighten security and allow only necessary communications.
In extra-scope rules, destination labels must match those used in the scope, while source labels can be outside the scope.
MySQL may not be part of the HRM application (for example, the destinations are “Global” and are not restricted by the labels in the scope).
Note
If the RBAC user's scope coverage type is “Sources and Destinations,” the user cannot select an IP list as the Destination. To select an IP list as a Destination in a rule, the scope coverage type must be “Sources Only.” For more information, see "Role-Based Access Control" in PCE Administration Guide.
Note
Understanding and correctly applying Intra-Scope and Extra-Scope rules in Illumio is crucial for effective application microsegmentation and security.•
Begin with broad rules and refine them over time to strike a balance between security and operational efficiency.
Custom iptables Rules
Note
The ability to create iptables rules is only enabled when the PCE is configured to display it.
Illumio supports custom iptables rules to keep configurations from native Linux host setups. This allows users to include custom iptables rules within the policy, ensuring new rules do not override existing Linux configurations.
Suppose you can configure iptables directly on your Linux workloads for your application workloads as part of your host configuration. However, when you pair a workload and put a policy into the Visibility Only or Full enforcement mode, the VEN assumes control of the iptables to enact the policy and does not apply any pre-programmed iptables to the policy.
Custom iptables rules in Illumio Core enable you to program the custom iptables rules needed for your applications as part of the rules managed by the PCE. Custom iptables rules help preserve any configured iptables from native Linux host configurations by allowing you to include them with the rules for your policy.
iptables refer to a Linux host configuration before the VEN is installed.
Rules refer to statements the PCE writes to determine permitted traffic, typically by assuming control of iptables and programming the new rules.
iptables rules refer to iptables inserted as rules onto the VENs and managed by the PCE.
Custom rules follow the iptables -A (append) command pattern:
-t<table>-A<chain> <rule>
Example:
-t filter -A INPUT -p tcp -s 10.10.10.10 --sport 8888 -j ACCEPT
Custom iptables rules consist of a list of iptables statements and the entities to which the rules are applied. Each rule can consist of a list of iptables rules, which allows users to group a sequence of rules for a specific function. The custom iptables rules are programmed after the Illumio PCE generates the iptables rules, but before the last default rule.
Before they are sent to the VEN, the custom iptables rules are checked for unsupported tokens (such as names of firewall chains already in use by Illumio, matches against IP sets, and semicolons). The rule cannot be saved or provisioned if an unsupported token is included.
If the VEN fails to apply a custom iptables rule because of a missing package or an incorrectly formatted rule:
The error is reported to the PCE and logged in the organization's event logs.
The error is displayed in the VEN policy sync status.
The new policy is not used, and the last successful policy is used instead.
For policy distribution and enforcement, the VEN creates a custom chain that contains the rules for each table or chain in the iptables. Each custom chain is appended to the end of its corresponding chain in the correct table. When the VEN requests the policy, the iptables command is sent, including the chain where it should be placed.
For security reasons, custom iptables rules only support rules in the mangle, nat, and filter tables.
The following table describes the permitted actions for each iptables type:
Table Name | Chain Names | Custom Rules Support |
|---|---|---|
| prerouting, output | No |
| prerouting, input, output, forward, post routing | Yes |
| prerouting, output, post-routing | Yes |
| input, output, forward | Yes |
| input, output, forward | No |
Note
If the RBAC user's scope coverage type is “Sources and Destinations,” the user cannot manage custom iptables rules. To allow access to custom iptables rules, the scope coverage type must be “Sources Only.” For more information, see "Role-Based Access Control" in PCE Administration Guide.
For more information about APIs, see "Custom IP Tables Rules Reference" in REST API Developer Guide.
Rules for Application Policies
Illumio allows or denies traffic between applications using policies that you write. To write application policies, you must create rules for the policy.
You can define and manage rules to control and secure communication within and between application groups.
Illumio has the following types of rules for application policies:
Application Policy Rule Types
There are three types of Application Policy rules:
Note
From the release 25.2.10, all rule types (Allow, Deny, and Override Deny rules) support label exclusion.
The ability to use an "all labels except. . ." approach when selecting labels for your rules was previously available only for Allow rules.
Override Deny Rules
Note
Override Deny rules require VEN release 22.3.0 or later.
These rules block all traffic, regardless of any other rules listed below them in the policy.
Because they have the highest precedence, they can't be overridden by another rule, such as any implemented Allow rules. If an administrator creates an Allow rule by mistake, the Override Deny Rule, which denies such communication, acts as a safeguard.
They are used to stop traffic completely, especially during a security breach.
Create an Override Deny rule:
Go to Policies and click Add.
Select Override Deny Rule and then click Add Rule.
In Sources, select one or more sources.
In Destinations, select one or more destinations.
In Destination Services, select one or more services.
Click Save.
Override Deny rule implementation.
There are various implementations for Override Deny rules, such as:
Blocking all traffic between your Production and Development environments except over
splunk-data (007 TCP)Additionally, blocking all traffic between all workloads over SSH with no possible exceptions (highest precedence)
To satisfy these requirements, proceed as follows:
Add a Deny rule specifying 'Production' as the source and 'Development' as the destination, blocking all services.
Add an Allow rule specifying the same source and destination, permitting traffic over
splunk-data (9997TCP).Add an Override Deny rule blocking all traffic between all workloads over SSH. Because this rule has the highest precedence, it cannot be overridden by an Allow rule.
Allow Rules
Allow rules have the second highest priority, after Override Deny rules.
They allow traffic to and from specific workloads. They act like security guards, permitting only registered or authorized traffic, and are used to define explicitly permitted traffic.
Deny Rules
Deny rules temporarily block specific traffic, often during initial setup. They are useful for blocking known problematic traffic while determining what should be allowed.
In the Allow List model transition, Deny rules are gradually replaced with Allow rules, which specify precisely which traffic is permitted.
Implementing Deny Rules During the Transition to Allow Rules
Start with deny rules to block risky traffic.
Monitor traffic patterns to understand what needs to be allowed.
Create the Allow rules for essential, trusted traffic.
Gradually remove deny rules as the Allow rules are established.
Once the Allow rules are fully enforced, all traffic is denied by default unless explicitly allowed by an Allow rule. Full enforcement of Allow rules ensures a secure and controlled network environment.
Conflicted Rules panel
You are now alerted when rules in the same or another policy in your organization conflict with one or more other rules.
Click the yellow icon to display a panel with the conflict details. Use the information to perform housekeeping on your policy or troubleshoot unexpected policy behavior.
Rules conflict when:
Traffic allowed by an Allow rule in your policy is overridden by an Override Deny rule in the same or another policy in your organization.
Result: Traffic is denied, which you may or may not have intended.
Traffic denied by a Deny rule in your policy is overridden by an Allow rule in the same or another policy in your organization.
Result: Traffic is allowed, which you may or may not have intended.
Stateful vs. Stateless Rules
By default, all rules you write in the PCE are stateful, which means that the host's firewall keeps track of a connection for the entire duration of the session.
Stateless Rules
For workloads, you can specify stateless packet filtering for a rule (“stateless”: true). This means that the VEN instructs the host's firewall not to maintain persistent connections for all sessions. You can create this type of stateless rule for data center core services, such as DNS and NTP.
Caveats
In a stateless rule, you can add the following policy objects as destinations:
An individual workload
A label (one each of a specific type, up to four total)
Any IP list plus all workloads
If you attempt to add any other destinations, you receive an error.
The limit ensures that the number of stateless rules is capped at 100, allowing both stateful and stateless rules to coexist on the host in a way that optimizes system and network performance. If you require more than 100 stateless rules in your Illumio policy, please get in touch with your Illumio Professional Services Representative for further information.
Warning
Existing active connections on workloads allowed by a stateless rule (for example, an SSH session) are terminated when workloads receive new rules from the PCE. Those connections need to be reestablished by the clients. For this reason, Illumio recommends using stateless rules for services that utilize high-frequency, short-lived connections, such as DNS and SNMP.