Rulesets

You use rulesets to write policies so the workloads in your network can communicate with each other. A ruleset features different types of rules:

  • Override Deny Rules: Define which traffic from the specified source to the specified destination will be disallowed, irrespective of whatever Allow rules exist in the system.
  • Allow Rules: Define which traffic from the specified source to the specified destination will be allowed. 
  • Deny Rules: Define which traffic from the specified source to the specified destination, that is not otherwise specifically allowed by an Allow rule, will be denied.

About Rulesets

Each rule specifies sources and destinations, as well as the allowed or denied source processes/services and destination services. Each source or destination must have a selected policy object (label, label group, service, IP list, or user group) that is either allowed or denied.

Rules define which workloads are allowed to communicate. Labels allow you to specify the aspects of workloads that you wish to include in your rules. The following are categories of labels that describe aspects of workloads:

  • Role: What activity (for example, Web or DB), are these workloads performing?
  • Application: To what application (for example, ERP or HRM) do these workloads belong?
  • Environment: In which type of environment (for example, development, production, or testing) are these workloads? 
  • Location: Where are these workloads located—either physically (for example, rack server or AWS) or geographically (for example, US, EU, or CA)?

For example, a ruleset defined as ERP | Prod | US, means that the rules apply to any workload that meets the following three requirements: 

  • Workloads that are part of the ERP application
  • Workloads that reside in the Prod (Production) environment
  • Workloads that reside in the US location

You can specify Services to allow or deny in the rule. Services are the specific applications storing, manipulating, presenting or communication data. The following are examples of source services:

  • dllhost.exe
  • cmd.exe

The following are examples of destination services:

  • SMB
  • Telnet
NOTE:

When the service in a rule is DNS, the source must be an IP List.

Ruleset Status

You can view the ruleset status on the Ruleset page. The current status of each ruleset (enabled or disabled) is displayed in the Status column. When you change a ruleset but haven't provisioned the change yet, the type of change (addition, deletion, or modification) appears in the Provision Status column with the word “Pending” to indicate that these changes must be provisioned to be applied.

Filter the Rulesets List

You can filter the rulesets list using the label and property filter at the top of the list. You can filter the list by entering a label type to show only those rulesets that use the selected labels. You can further filter the list by selecting specific properties of the rulesets. For example, you can filter the list by provision status, such as rulesets that are in draft state and have not yet been provisioned.

Create a Ruleset Using Policy Templates

You can create a ruleset to write rules that define the allowed communication between workloads in a single group or multiple groups. See Groups in Illumination in the Visualization Guide for information.

The easiest way to do this is to use best-practice rulesets made from policy templates that Illumio has created for you.

To create a ruleset using an Illumio template: 

  1. From the PCE web console main menu, choose Rulesets and Rules > Rulesets.

    The Rulesets page appears.

  2. Click + Add from template.
  3. In the Add Best Practice Ruleset dialog, select a Ruleset option, such as Block NetBIOS or Block RDP, depending on what traffic you want to deny. Illumio periodically updates the list of Ruleset options, so be sure to scroll all the way through the dialog menu to see which ones are best for you.

    The Show Preview of Rules screen appears.

    NOTE:

    One best practice ruleset, Protect MSFT Domain Controllers, comes populated with both Allow and Deny rules, and requires you to select Labels and/or Workloads for the Domain Controller before you see the Show Preview of Rules screen.

  4. In the Show Preview of Rules screen, if the ruleset is the one you want, select Next.

    The Preview Impact of Rules screen appears.

  5. In the Preview Impact of Rules screen, if the impact is the one you want, select Next. (If there is not yet traffic that would be affected, the screen will say so.)

    The Confirm and Save screen appears.

  6. If the default name is a duplicate, change it. If desired, enter a brief description of the Ruleset.
  7. Click Confirm and Save.

    Now that the ruleset is created, you can add further rules to define your security policy. See Rules for information about the types of rules you can add.

    Your ruleset will not take effect until you provision it. See Provisioning for more information.

Create a Ruleset Manually

You can manually create a ruleset to write rules that define the allowed communication between workloads.

When you write a rule for a Windows workload, if you add a Windows service name without specifying any port or protocol, the rule will allow communication for that service over any port or protocol.

NOTE:

Illumio recommends creating no more than 500 rules per ruleset, or the PCE web console will not be able to display all of the rules. If you want to create a ruleset with more than 500 rules, Illumio recommends splitting the rules across multiple rulesets.

To create a ruleset manually: 

  1. From the PCE web console main menu, choose Rulesets and Rules > Rulesets.

    The Rulesets page appears.

  2. Click Add from scratch.
  3. Enter a name and description for the ruleset.
  4. Click the dropdown Add button to select Override Deny, Allow, and/or Deny Rules for the ruleset.

    The desired rule type expands, and displays the following fields:

    • Sources (Select one or more Workloads)
    • Source Processes/Services (Select one or more Services)
    • Destinations (Select one or more Workloads)
    • Destination Services(Select one or more Services)

    NOTE:

    Only Allow rules have options (SecureConnect, Machine Authentication, and Stateless).

    If the Source Processes/Services field is populated with one or more services, you cannot use an IP list as a destination.

    If you select a Windows Outbound Service for your Source Service, you must also specify an Inbound (Destination) Service.

  5. Select one or more values for each of the fields. In addition to scrolling, you can type in the field and it will present suggestions, irrespective of the kind of process or service. However, in Source and Destination dialogs you can select the Advanced Options check box to search only specific categories.

  6. When you have populated the desired fields, click the Save icon.

    Now that the ruleset is created, you can add further rules to define your security policy or add a note. At time of writing, you cannot add a note to Deny or Override Deny rules, but you can add them to Allow rules. See Rules for information about the types of rules you can add.

    Your ruleset will not take effect until you provision it. See Provisioning for more information.

Duplicate a Ruleset

When you have a ruleset that you want to use to create other new rulesets, you can duplicate an existing ruleset.

  1. From the PCE web console main menu, choose Rulesets and Rules > Rulesets.

    The Ruleset list page appears.

  2. Click the vertical breadcrumb icon to the right of the ruleset you wish to duplicate, and then click Duplicate Ruleset.

    The Duplicate Ruleset page appears.

  3. Rename the copy of the ruleset.

    NOTE:

    The default name is “Copy of [Ruleset Name]” (where [Ruleset Name] is the name of the original Ruleset).

  4. Click Save.

After saving the new duplicate ruleset, make any needed changes and then provision to apply them.

See Provisioning for more information.

Ruleset Caveats

Do not delete any of the objects (e.g., labels, rulesets, pairing profiles, or services) associated with an endpoint group. This will break the onboarding, pairing, etc., which may result in unexpected behavior.