Skip to main content

Protocol Enforcement Rules

Protocol Enforcement Rules provide broad, protocol-based controls that apply across all machines in your environment. Unlike connection rules that specify allowed communications between specific machines, protocol enforcement rules control traffic based on port numbers and transport protocols (TCP/UDP)—regardless of machine identity.

These rules are synchronized to all Corsha Gatekeepers in your environment and always take precedence over individual connection rules.

Policy Overview

See Managing Policies for an overview of all policy types, their precedence, and when to use each type.

Overview​

Protocol enforcement rules enable you to:

  • Block unwanted protocols: Prevent specific protocols (e.g., FTP, Telnet) across your entire environment
  • Allow essential services: Permit necessary protocols in Block by Default environments
  • Restrict port access: Control traffic on specific ports globally
  • Override connection rules: Protocol enforcement takes precedence when conflicts occur

Rule Components​

A protocol enforcement rule consists of three components:

  • Action: Specify whether to Allow or Block matching traffic
  • Ports: Specify port numbers or port ranges
    • Enter individual ports separated by commas: 80, 443, 8080
    • Specify ranges using a hyphen: 8000-8010
    • Combine both formats: 80, 443, 8000-8010
  • Transport Protocol: Specify TCP, UDP, or both

Rule Precedence​

The Corsha Gatekeeper applies rules in the following order of precedence:

  1. Baseline Mode: The Corsha Gatekeeper's default mode (Allow by Default or Block by Default) determines the starting point
  2. Protocol Enforcement Rules: These global rules are applied based on the baseline mode
  3. Connection Rules: Individual machine-to-machine connection rules are overridden by protocol enforcement rules

Important: Protocol enforcement rules always override connection rules when there are conflicts.

For example:

  • If a connection rule allows Machine A → Machine B on TCP port 502
  • But a protocol enforcement rule blocks TCP port 502
  • The connection will be blocked in Allow by Default mode (protocol enforcement wins)
  • In Block by Default mode, the Block protocol rule is skipped, and the Allow connection rule remains in effect

This precedence model enables you to enforce organization-wide security policies that cannot be bypassed by connection rules in Allow by Default environments.

Enforcement Mode Interaction​

Protocol enforcement rules interact with Corsha Gatekeeper enforcement modes:

In Allow by Default Mode​

  • Only Block protocol enforcement rules are enforced
  • Allow protocol enforcement rules are skipped (since traffic is already allowed by default)
  • Inactive rules are not enforced
  • Use this mode to incrementally block unwanted protocols

Example: If you create a Block rule for TCP ports 80 and 443, all HTTP and HTTPS traffic will be denied globally, while all other traffic continues to flow freely.

In Block by Default Mode​

  • Only Allow protocol enforcement rules are enforced
  • Block protocol enforcement rules are skipped (since traffic is already blocked by default)
  • Inactive rules are not enforced
  • Use this mode for strict zero-trust environments

Example: If you create an Allow rule for TCP port 4840, OPC UA traffic will be permitted for all devices, while all other traffic remains blocked by the baseline.

In Observe-Only Mode​

  • Protocol enforcement rules are logged but not enforced
  • Use this mode to test rules before enforcement

Examples​

Example 1: Blocking Web Traffic​

Scenario: You want to block all HTTP and HTTPS traffic across your network.

  • Baseline: Allow by Default (all traffic is open)
  • Protocol Enforcement Rule: Create a "Block" rule for TCP ports 80 and 443
  • Result: All traffic on ports 80 and 443 is blocked for all machines. Any Allow rules are not enforced due to the baseline mode being Allow by Default.

Example 2: Allowing OPC UA Traffic​

Scenario: You want to allow OPC UA traffic in a locked-down environment.

  • Baseline: Block by Default (all traffic is closed)
  • Protocol Enforcement Rule: Create an "Allow" rule for TCP port 4840
  • Result: All traffic on port 4840 is allowed for all machines. Any Block rules have no effect since the baseline mode is Block by Default.

Example 3: Protocol Rules Override Connection Rules​

Scenario: You have an Allow by Default baseline and want to block Modbus TCP traffic globally, but you previously created a Connection Rule allowing Modbus traffic between two specific machines.

  • Baseline: Allow by Default
  • Protocol Enforcement Rule: Create a "Block" rule for TCP port 502
  • Connection Rule: "Allow" TCP port 502 traffic between Machine X and Machine Y
  • Result: In Allow by Default mode, the Block protocol enforcement rule is enforced and takes precedence. All Modbus TCP traffic on port 502 is blocked globally, including the traffic between Machine X and Machine Y, despite the Allow connection rule.

Example 4: Rules for Different Ports (No Conflict)​

Scenario: You want to block specific industrial protocols while allowing targeted restrictions between specific machines.

  • Baseline: Allow by Default
  • Protocol Enforcement Rule: "Block" TCP and UDP port 44818 for EtherNet/IP (ENIP) traffic
  • Connection Rule: "Block" TCP ports 20-21 between Machine X and Machine Y for FTP traffic
  • Result: The rules do not conflict, and both are applied:
    • All TCP and UDP 44818 ENIP traffic is blocked for all machines (per the Protocol Enforcement rule)
    • TCP 20-21 FTP traffic is blocked only between Machine X and Machine Y (per the Connection Rule)
    • All other traffic is permitted (as per the Baseline)

Managing Protocol Enforcement Rules​

Console Integration

Protocol enforcement rules can be managed through the Console. Contact your Corsha TPOC for assistance with Console access and rule configuration.

Accessing the Console​

Navigate to the Policies page in the Console. The Enforcement by Protocol table appears at the top of the page, with Connection Rules displayed below.

Empty state of Enforcement by Protocol table

The Enforcement by Protocol section when no rules have been created yet.

Understanding the Rules Table​

Each rule in the Enforcement by Protocol table displays:

  • Status chip: A colorful indicator showing whether the rule is:
    • 🟩 Allowed: Permit traffic matching this rule
    • 🟥 Blocked: Deny traffic matching this rule
    • ⬜ Inactive: The rule is disabled and will not be enforced
  • Protocol: The transport protocol (TCP, UDP, or both) the rule applies to
  • Port summary: A human-readable summary of the ports covered by the rule

Rules displayed in the table

Each rule shows a status chip, protocols, and port summary.

Port Number Summarization​

The Console automatically summarizes port numbers for better readability:

  • Individual ports are listed separately (e.g., "80, 443, 8080")
  • Consecutive ports are shown as ranges (e.g., "8000-8010")
  • Mixed formats combine both styles as needed (e.g., "80, 443, 8000-8010")

Example of individually listed ports

When ports are non-consecutive, they are listed individually.

Example of summarized port ranges

Consecutive ports are automatically displayed as ranges.

Creating Rules​

To create a new protocol enforcement rule:

  1. Click the Create New Rule button
  2. Configure your rule:
    • Description (optional): Add notes about the purpose
    • Protocol (required): Select TCP, UDP, or both
    • Port (required): Enter port numbers or ranges
    • Action (required): Choose Allow or Block
  3. Click Create to save

The rule is immediately synchronized to all Corsha Gatekeepers in your environment.

Create new rule dialog

The Create New Rule dialog with all configuration fields.

Modifying Rules​

To change the status of one or more rules:

  1. Select the checkbox(es) next to the rule(s)
  2. Use the action dropdown in the upper-right corner
  3. Choose allow, block, or ignore (inactive)
  4. Click the button to proceed
  5. Review and confirm the changes

Selecting a rule to modify

Select rules using checkboxes and choose an action.

Confirmation modal for rule changes

Confirm changes before applying them.

Updated rule after modification

The rule status updates immediately after confirmation.

Filtering and Searching​

Use the filter controls above the table to find specific rules:

  • Search: Find rules by description, port numbers, or protocols
  • Filters: Apply specific criteria to narrow down the list

The search functionality works even within summarized port ranges.

Searching within summarized port ranges

Search finds rules even when searching for specific ports within a range.

To clear filters, click individual filter chips or use Clear filters to remove all at once.

Filters applied to the table

Active filters are displayed as chips above the table.

Toggling Rules​

Protocol enforcement rules can be toggled between active and inactive states without deletion. This allows you to:

  • Temporarily disable rules for troubleshooting
  • Test rule impacts before full deployment
  • Preserve rule definitions for future use

Avoiding Rule Conflicts​

Do not create opposing protocol enforcement rules for the same port/protocol combination. The system does not currently de-conflict opposing rules. You can create conflicting rules such as:

  • Rule 1: Allow TCP 8080
  • Rule 2: Block TCP 8080

This configuration is not recommended, and the resulting behavior is undefined. To prevent issues, review existing rules before creating new ones that target the same ports and protocols.

Testing Protocol Rules​

Before deploying protocol enforcement rules in production:

  1. Deploy Corsha Gatekeepers in Observe-Only mode to understand existing traffic
  2. Review logs to identify protocol usage patterns
  3. Create test rules and verify expected behavior in staging
  4. Monitor Connection Canvas after rule activation

Common Use Cases​

Blocking Insecure Protocols​

Create Block rules for protocols that should not be used in your environment:

  • FTP (TCP ports 20-21)
  • Telnet (TCP port 23)
  • HTTP (TCP port 80) if you require encrypted traffic only
  • Insecure SNMP (UDP port 161)

Allowing Essential Services​

In a Block by Default environment, create Allow rules for necessary protocols:

  • HTTPS (TCP port 443)
  • DNS (UDP port 53)
  • NTP (UDP port 123)
  • Industrial protocols specific to your environment

Progressive Security Hardening​

If you're starting with Allow by Default:

  1. Begin by monitoring traffic to understand your network patterns
  2. Gradually add Block rules for protocols you've identified as unnecessary or risky
  3. Over time, transition to a more secure posture by blocking more protocols
  4. Eventually consider switching to Block by Default for maximum security

Best Practices​

  1. Use sparingly: Protocol enforcement is a broad hammer—use it for organization-wide policies, not machine-specific restrictions
  2. Start with Block rules: In Allow by Default mode, incrementally block unwanted protocols
  3. Document rationale: Add descriptions explaining why each protocol rule exists
  4. Test before blocking critical protocols: Blocking essential protocols can cause widespread outages
  5. Combine with connection rules: Use protocol enforcement for broad policy, connection rules for specific access
  6. Avoid rule conflicts: Never create opposing rules for the same protocol/port combination
  7. Understand mode interaction: Remember that only Block rules work in Allow by Default, and only Allow rules work in Block by Default

Next Steps​