ExamFinch.com My Study

Study guide

2.5 Access Rules: Fields, Actions, and Track Options

Practice this exam

CCSA R82 — Check Point Certified Security Administrator Study Guide Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & Architecture

1.1 CCSA R82 Exam Facts 1.2 Standalone vs Distributed Deployment 1.3 Gaia OS, clish and expert Mode 1.4 The SmartConsole Suite 1.5 Secure Internal Communication and the ICA

2 Chapter 2: Security Policy & Access Control

2.1 Policy Packages 2.2 Access Control Policy Overview 2.3 Ordered Layers and First-Match Evaluation 2.4 Inline Layers and Nested Rule Matching 2.5 Access Rules: Fields, Actions, and Track Options 2.6 Implied Rules and Global Properties 2.7 Stealth and Cleanup Rules: Placement and Best Practice 2.8 Hit Count and Policy Install Workflow

3 Chapter 3: Network Address Translation (NAT)

3.1 NAT Overview in Check Point 3.2 Hide NAT (Many-to-One) 3.3 Static NAT (One-to-One) 3.4 Automatic vs Manual NAT and Proxy ARP

4 Chapter 4: Identity Awareness

4.1 Identity Awareness Overview 4.2 Active Directory Query 4.3 Identity Collector 4.4 Identity Agent 4.5 Captive Portal and Access Roles

5 Chapter 5: Threat Prevention

5.1 Threat Prevention Overview 5.2 Application Control 5.3 URL Filtering 5.4 Intrusion Prevention System (IPS) 5.5 Anti-Bot and Anti-Virus 5.6 Threat Emulation and Threat Extraction 5.7 TP Profiles, Best Practice, and Ordered Layers for TP 5.8 HTTPS Inspection

6 Chapter 6: ClusterXL — High Availability, Load Sharing, and Failover

6.1 ClusterXL Overview: Why Clustering, HA vs Load Sharing 6.2 High Availability Mode: Active/Standby, Primary Up vs Active Up 6.3 Load Sharing Modes: Multicast, Unicast (Pivot), and Traffic Distribution 6.4 Cluster Control Protocol (CCP) and State Synchronization 6.5 Failover, Cluster States, and Troubleshooting with cphaprob

7 Chapter 7: VPN, Logs, and Troubleshooting

7.1 Site-to-Site IPsec VPN 7.2 Remote Access VPN 7.3 Encryption Domains and VPN Communities 7.4 Mobile Access Blade 7.5 Logs, Monitor, and SmartEvent 7.6 Backups, Snapshots, and Migrate Export 7.7 fw monitor, fw ctl zdebug, and cpview 7.8 cpinfo and Common Issues

2.5 Access Rules: Fields, Actions, and Track Options

Key Takeaways Explain This Topic AI

An Access Control rule has Source, Destination, VPN, Service, Action, Track, Install On, Time, and Comments fields

The five primary actions are Accept, Drop, Reject, Inform, and Ask

Track options include None, Log, Alert, Mail, SNMP Trap, Accounting, and User Alert

Drop silently discards the packet; Reject drops it and sends a response (TCP RST or ICMP unreachable) to the source

  • Track options determine what is logged and how administrators are notified
  • Last updated: July 2026

The Anatomy of an Access Rule

Every rule in an Access Control layer has the same core fields, visible as columns in SmartConsole's Access Control rulebase:

  • Field Purpose
  • Number Position in the layer; rule order matters (first match wins)
  • Source Source IP addresses, networks, address ranges, or groups; can include identity-aware objects
  • Destination Destination IP addresses, networks, ranges, or groups
  • VPN VPN community the rule applies to, or Any
  • Service TCP/UDP ports, ICMP, protocols, or application signatures

Action What the gateway does when the rule matches: Accept, Drop, Reject, Inform, Ask, or invoke an inline layer

  • Track What is logged or alerted: None, Log, Alert, Mail, SNMP Trap, Accounting, User Alert
  • Install On Which gateways enforce this rule (default: All Gateways)
  • Time Schedule when the rule is active
  • Comments Free-text documentation

A rule matches when all of its match fields match the connection — Source AND Destination AND Service AND VPN AND Time. If any match field does not match, the rule does not match and evaluation moves to the next rule.

Match Fields in Detail

Source and Destination accept any combination of: single IP, network object, address range, group of objects, or the special Any object. They can also include identity-aware objects when Identity Awareness is enabled — for example, a group named Finance-Users populated from Active Directory.

Service defines the protocols and ports. R82 ships with hundreds of built-in services (http, https, ssh, dns, smtp, sqlnet, etc.) and supports custom services. Groups of services can be used to match multiple ports in one rule.

VPN restricts the rule to traffic arriving over a specific IPsec VPN community. Setting VPN to Any means the rule applies regardless of whether the traffic arrived over VPN.

Time binds the rule to a configured Time object (for example, business-hours). Outside the schedule, the rule is skipped during evaluation.

Actions in R82

The action is the most-tested field. The five primary actions are:

Accept — allow the connection. Evaluation typically continues to the next ordered layer and then to Threat Prevention for accepted traffic.

Drop — silently discard the connection. No response is sent to the source. Evaluation stops; subsequent ordered layers are not evaluated.

Reject — discard the connection and notify the source. For TCP, the gateway sends a RST; for UDP, it sends an ICMP port-unreachable. Evaluation stops. Reject is useful when you want the source to know its traffic was refused (helps users notice a misconfiguration quickly) but it leaks slightly more information than Drop.

Inform — log the connection without enforcing the rule's action; the connection continues as if the rule had not matched. Useful for monitoring traffic that you do not want to enforce yet.

Ask — prompts the user (typically through a Captive Portal or UserCheck) before applying the rule. Used with Identity Awareness to interactively confirm access.

A rule can also have an action of Inline Layer (invoke a nested inline layer) or Drop with Reason (a Drop variant that includes a textual reason in the log).

Drop vs Reject

The Drop-vs-Reject distinction is a CCSA staple. Drop is silent : the source sees its packets disappear into a black hole and must time out. Reject is explicit : the source receives a TCP RST or ICMP unreachable and learns immediately that the connection was refused. Security best practice generally prefers Drop for Internet-facing rules because Reject confirms to an attacker that a firewall is present and can leak protocol information. Reject is more user-friendly for internal users who misconfigured a destination and would benefit from immediate feedback.

Track Options

The Track field controls logging and alerting when a rule matches:

  • Track Behavior
  • None No log entry is written
  • Log Write a log entry for the connection (start and/or end, depending on rule logging settings)
  • Alert Write a log entry and trigger an alert (visible in SmartConsole's Logs and Monitor tab)
  • Mail Write a log entry and send an email alert
  • SNMP Trap Write a log entry and send an SNMP trap to a configured manager
  • Accounting Log session accounting data (bytes, duration)
  • User Alert Display a user-facing alert (used with Identity Awareness and UserCheck)

A common pattern is to set Accept rules to Log and Drop rules to Log or Alert, so the firewall has a complete picture of allowed and denied traffic. Drop rules that match suspicious or repeated scans are often set to Alert or Mail for proactive notification.

Install On and Time

The Install On field lets a rule target specific gateways. By default, the field is set to All Gateways, meaning every gateway that receives this policy package enforces the rule. You can restrict a rule to a specific gateway or group of gateways, useful for rules that reference interfaces or networks present on only one gateway.

The Time field binds a rule to a Time object. A rule with a Time object of Business-Hours only evaluates during those hours; outside the schedule, the rule is invisible to evaluation. This is useful for change windows, after-hours access, and time-based partner access.

Worked Example

A rule with:

  • Source: Net-Internal
  • Destination: Net-DMZ
  • Service: http
  • Action: Accept
  • Track: Log
  • Install On: All Gateways
  • Time: Business-Hours

…matches HTTP connections from internal hosts to the DMZ during business hours, accepts them, logs the connection, and applies on every gateway that receives the policy package. Outside business hours the rule does not match, and the connection falls through to subsequent rules — likely the cleanup Drop at the bottom of the layer.

Best Practices

Be specific in match fields. Use the smallest scope that satisfies the requirement; avoid Any in production rules where possible.

Track every security-relevant rule. Log Accept and Drop at minimum; use Alert for sensitive rules.

Document with Comments. Include a change ticket ID or rationale for every non-obvious rule.

Prefer Drop over Reject on Internet-facing rules to avoid leaking firewall presence.

Use Time objects for temporary access so the rule automatically deactivates.

Why This Matters for the Exam

Expect questions that present a rule and ask what happens to a connection: which field matched, what action was applied, what was logged, and whether evaluation continued. Read every field of the rule, not just the action — a rule with the wrong Time or Install On setting may not match at all.