2.6 Implied Rules and Global Properties

What Implied Rules Are

Implied rules are pre-defined, system-level rules that allow the control and management traffic required for the gateway, management server, and Check Point infrastructure to function. Without them, a freshly installed gateway with no explicit rules would drop SIC, IKE, DNS, RADIUS, and other essential protocols — making the gateway unmanageable. Implied rules are implicit: they do not appear in the Access Control rulebase by default, and they are applied automatically based on settings in the Global Properties.

Because they are not visible in the rulebase, implied rules are a common source of confusion on the CCSA exam. They can also be a source of unintended access in production: an implied rule that allows a broad protocol can let traffic through that an administrator believes is blocked by the explicit rulebase.

Where Implied Rules Live

Implied rules are configured in SmartConsole under Global Properties > FireWall-1 > Implied Rules. The Implied Rules panel groups the rules into four categories that determine their position relative to the explicit Access Control rulebase:

1. Implied rules before the explicit rules — applied first, before any rule in the Access Control rulebase. These typically include SIC and gateway-to-management communication so the gateway can be managed even if the explicit rulebase blocks everything.
2. On Gateway rules — applied on the gateway itself, typically for traffic that originates or terminates on the gateway (for example, IKE/ESP for site-to-site VPN).
3. Control connections — rules for management protocols that need to reach the gateway (for example, RADIUS, TACACS, DNS).
4. Implied rules after the explicit rules — applied after the explicit rulebase. These are broader 'convenience' rules that allow certain common protocols if no explicit rule denied them.

Each category has individual toggles. For example, you can enable or disable the implied rule that allows SIC, the implied rule that allows outgoing DNS, or the implied rule that allows RADIUS.

Common Implied Rules

Typical implied rules that the CCSA exam expects you to recognize include:

• SIC (Secure Internal Communication) — allows communication between the management server and the gateway on TCP port 18211 (and related ports).
• IKE and ESP — allows UDP 500 and IP protocol 50/51 for IPsec VPN negotiation and encrypted traffic.
• RADIUS and TACACS — allows the gateway to authenticate users against external authentication servers.
• DNS — allows the gateway to resolve DNS for its own services.
• ClusterXL control connections — allows CCP (Check Point Cluster Protocol) traffic between cluster members.
• Outgoing HTTP/HTTPS from the gateway — in some configurations, allows the gateway to fetch updates.

Why Implied Rules Are Not in the Rulebase

Implied rules exist for two reasons. First, they protect essential services: if an administrator accidentally wrote a cleanup Drop that blocked SIC, the gateway would become unmanageable. Placing SIC in an implied rule before the explicit rulebase guarantees the management connection works regardless of rulebase mistakes. Second, they reduce clutter: these protocols must always be allowed, and showing them as explicit rules would crowd the rulebase.

The trade-off is invisibility. An administrator reading the rulebase may believe a protocol is blocked when an implied rule actually permits it. To make implied rules visible in SmartConsole, use View > Implied Rules. This adds them to the displayed rulebase with a special icon and an Implied Rules section so you can audit what is allowed at the implied level.

Controlling Implied Rules

Administrators control implied rules in three ways:

• Enable or disable individual implied rules in Global Properties. For example, if the gateway does not use RADIUS, disable the RADIUS implied rule to reduce implicit access.
• Move an implied rule's position by changing its category. Moving an implied rule from 'before the explicit rules' to 'after the explicit rules' makes it subject to explicit Drops above it.
• Replace an implied rule with an explicit rule. Best practice in high-security environments is to disable broad implied rules and add explicit rules with specific source/destination and Track settings so the access is logged and auditable.

Implied Rules vs Explicit Rules

A Common Exam Trap

A scenario question may describe a connection that should be dropped by the explicit rulebase but is allowed. The trap is to look at the explicit rules, conclude the connection is dropped, and miss the implied rule that actually allows it. For example, the gateway itself can initiate DNS queries even if the rulebase has a cleanup Drop at the bottom, because the outgoing DNS implied rule sits in the 'On Gateway' or 'before explicit rules' category.

When a question asks why a connection was allowed despite the explicit rulebase appearing to drop it, ask: is the source or destination the gateway itself? Is the protocol one of SIC, IKE, ESP, DNS, RADIUS, or CCP? If so, an implied rule is the likely answer.

Best Practices

• View Implied Rules during audits. Toggle the view on whenever you audit a rulebase.
• Disable unused implied rules. If you do not use RADIUS or TACACS, disable those implied rules.
• Replace critical implied rules with explicit rules in high-security environments to gain logging and granularity.
• Document any changes to implied rules in the policy's change log.

Why This Matters for the Exam

CCSA R82 tests the concept of implied rules, their location in Global Properties, the categories (before explicit, on gateway, control, after explicit), the common protocols (SIC, IKE/ESP, RADIUS, DNS, CCP), and the way to display them (View > Implied Rules). Expect at least one scenario where the explicit rulebase says Drop but an implied rule allows the connection.