CCSA R82 cheat sheet

Security Management Server stores the object database and rule base; Security Gateway enforces policy; SmartConsole is the GUI client that connects to the management server over SIC/CPMI ports.

SIC (Secure Internal Communication) uses certificates issued by the Internal CA; a gateway cannot be trusted or receive policy until SIC is initialized and its fingerprint verified.

Management HA uses an Active and Standby management server; the Standby synchronizes the object database and logs, and promotion is manual or automatic.

Distributed deployment separates management from enforcement; Standalone deployment runs both on one machine; only one management server may be Active for a given database.

Default management ports: SmartConsole/API (443/19009), CPMI (19009/18190 range), SIC (18211), and log transfer to management (257).

Full High Availability gateways use VRRP-style clustering with a Virtual IP; the cluster object defines members, and ClusterXL modes are HA, Load Sharing, and Multicast.

A gateway license controls blades and throughput; blades not licensed are not enforced even if configured in the rule base.

Upgrades follow the path: export database (migrate export), install new version, migrate import, then verify SIC and policy installation.

SmartConsole sessions are per-administrator; concurrent editing is controlled by session locks, and publish commits changes to the management database.

Changes made in SmartConsole are held in the private session until Publish; Install Policy pushes the published rule base to gateways.

Administrator authentication can be local, via RADIUS/TACACS, or via a remote directory; permissions derive from assigned profiles (e.g., Super User, Security Admin).

The Management API (Web API) exposes the same objects and commands as SmartConsole; login returns a session ID used in subsequent calls.

Object changes are versioned; 'Install Policy' can be scoped to specific gateways and installs only policies containing those gateways.

SmartConsole search and 'Where Used' reveal object dependencies before deletion; deleting an object in use is blocked or requires replacement.

Session history and audit logs record every administrative action with timestamp, administrator, and object affected.

Global policies and 'Global Properties' apply across all gateways; per-gateway policy overrides only where explicitly configured.

Rules are evaluated top-down; the first matching rule is enforced, so order determines precedence and shadowed rules never fire.

Each rule has Source, Destination, VPN, Service, Action, and Track; an implicit 'cleanup' rule drops traffic not matched by any explicit rule.

Inline Layer rules allow nested sub-policies; a parent rule can call an inline layer whose rules are evaluated before the parent's action applies.

The Action types include Accept, Drop, Reject (sends reset/ICMP unreachable), and Ask (user confirmation); Drop is silent, Reject informs the client.

Negation on Source/Destination/Service inverts the match; overuse of negation makes rules hard to audit and can create implicit accepts.

Section headers organize rules; a rule's position relative to sections affects evaluation only through top-down order, not by section type.

Policy installation compiles the rule base; verification warnings (e.g., shadowed rules, empty rules) appear before install and can be reviewed.

Track options (Log, Accounting, None) determine logging; 'Log' on an Accept rule records allowed sessions, which is essential for troubleshooting.

NAT rule types: Hide (many-to-one, source NAT), Static (one-to-one), and NAT44/46/64 for address-family translation.

NAT rules are matched top-down independently of the security rule base; the first matching NAT rule applies to the connection.

Original and translated packets are tracked separately; logs show both the original and NAT-translated addresses when NAT is applied.

Automatic NAT is derived from object NAT settings; manual NAT rules in the NAT policy override automatic rules when placed above them.

For Static NAT, the translated destination must be reachable and ARP/proxy ARP configured so the gateway answers for the public address.

Routing decisions use the routing table and policy-based routing; the gateway performs destination lookup after NAT translation for outbound flows.

VPN traffic may bypass NAT depending on 'Disable NAT inside the VPN community' settings; NAT and VPN interaction must be verified per community.

Proxy ARP is required when a static NAT public IP is not on a directly connected subnet, so the gateway responds to ARP for that address.

Identity sources: AD Query, Identity Collector, Terminal Servers (TS) agent, Captive Portal, and RADIUS accounting; each yields user-to-IP mapping.

AD Query reads domain controller security logs to map users to IPs; it requires a read-only service account and event log access.

Identity Collector is agent-based, scales better than AD Query, and receives identity events directly from domain controllers.

Captive Portal authenticates users on a browser redirect; the mapping persists per session and can be time-limited.

Identities can be used in rules as Source 'Access Role' or 'User'; unmatched identities fall to 'Unknown' or 'Guest' categories.

Identity Awareness requires the Identity Awareness blade and a gateway that can reach the identity source; the PDP (Policy Decision Point) stores mappings.

Access Roles group users, groups, and machines; they simplify rules and can be referenced across multiple rules.

Identity sharing lets one gateway share user-to-IP mappings with another, useful in distributed or remote-access deployments.

Application Control identifies applications by signature, not just port; it inspects traffic and classifies it into application categories and risk levels.

Application signatures are updated via the Application Control and URL Filtering update service; outdated signatures reduce detection accuracy.

Application/Site categories include risk (low/medium/high/critical) and productivity; rules can allow, block, or limit by category or specific application.

Application Control requires the Application Control blade and works with the Access Control policy; it is enforced on Accept rules with application objects.

Some applications use dynamic ports or SSL; SSL inspection (with the HTTPS Inspection blade) is needed to classify encrypted application traffic.

Application Control can apply per-user or per-group actions when Identity Awareness is enabled.

The 'Applications/Sites' database in SmartConsole lists applications with their category and risk; custom applications can be defined for internal apps.

Granular actions include Allow, Block, Ask, and Limit (bandwidth); Limit requires the appropriate blade and is applied to matched sessions.

URL Filtering categorizes web destinations into categories (e.g., Social Networking, Malware); rules allow or block by category or specific URL.

URL Filtering requires the URL Filtering blade and a valid contract for category updates; the URL database is updated regularly.

HTTPS traffic requires HTTPS Inspection to see the full URL and apply category-based blocking; without inspection, only SNI/domain may be visible.

Content Security includes Anti-Virus, Anti-Bot, and Threat Emulation; these blades inspect downloaded files and traffic for malicious content.

Anti-Virus scans files and protocols (HTTP, FTP, SMTP, POP3); it can block, quarantine, or allow with logging based on the protection profile.

HTTPS Inspection uses a certificate authority to re-sign traffic; the gateway CA certificate must be trusted by clients or inspection breaks.

Content Security profiles are attached to Accept rules; a rule without a profile performs no content inspection.

File types and protocols can be excluded from inspection; exclusions reduce false positives but create blind spots.

Threat Prevention combines IPS, Anti-Bot, Anti-Virus, Threat Emulation, and Threat Extraction; profiles define which protections apply.

IPS signatures have severities (Critical/High/Medium/Low) and can be set to Prevent, Detect, or Inactive per profile.

Threat Emulation sends suspicious files to a sandbox; Threat Extraction strips active content and delivers a sanitized file immediately.

Logs are stored on the management server or a dedicated Log Server; SmartLog and SmartEvent query these logs.

Log fields include origin, source, destination, service, action, blade, and protection name; these drive filtering and reporting.

SmartEvent correlates logs into events using correlation units; events can trigger alerts and automated reactions.

Log retention and indexing are configured per log server; excessive logging degrades performance and fills storage.

Indicators and IoCs from ThreatCloud feed protections; ThreatCloud is the cloud service that distributes signatures and reputation data.

cpstat and cpview show real-time gateway statistics (CPU, memory, connections, blades); cpview is interactive, cpstat is scriptable.

fw monitor captures packets at multiple inspection points (i, I, o, O) to see pre/post-NAT and pre/post-inspection traffic.

fw ctl zdebug (or fw ctl debug) enables kernel-level debug output; use filters to limit output and disable when finished.

cpinfo collects system and product diagnostics into a file for support; it includes versions, licenses, and configuration summaries.

fw stat and cpstat verify policy installation status; fw fetch pulls policy from the management server on the gateway.

tcpdump on the gateway captures raw packets; compare with fw monitor to distinguish routing/drop issues from inspection issues.

SmartView Monitor shows gateway health, alerts, and traffic; SmartLog/SmartEvent handle log-based troubleshooting.

Backups: migrate export for database migration, upgrade_export for upgrades, and cpbackup for full system backup; verify restores periodically.

The Internal CA issues certificates to management and gateways; resetting SIC requires re-initializing the gateway and re-establishing trust.

A Security Gateway can be a cluster member; cluster objects define the Virtual IP and member list, and policy installs to the cluster object, not individual members.

Management API and SmartConsole share the same backend; changes are validated against object schema before publish.

License and contract status are visible in SmartConsole; expired contracts stop signature and category updates but do not stop enforcement of existing policy.

Read-only administrators can view but not publish; profiles determine which blades and objects an administrator can edit.

Publish creates a new database revision; multiple administrators publishing concurrently may conflict and require resolution.

Install Policy can be limited to specific gateways and to specific policy packages; the install log reports success or failure per gateway.

The audit log is queryable and shows before/after values for object changes, supporting change tracking.

Rule verification flags: shadowed rules, rules that will never match, and rules with no logging; use these before install.

The 'Any' object in Source/Destination/Service matches broadly; explicit objects reduce accidental over-permission.

Policy packages can be assigned to multiple gateways; a gateway uses exactly one installed policy package at a time.

Time objects and 'Install On' targets scope rules to schedules and specific gateways, respectively.

Hide NAT translates many internal addresses to one public address using port translation; concurrent sessions are limited by available ports.

Static NAT maps one internal address to one public address one-to-one; it is used for inbound services.

NAT rules have Original and Translated columns for Source, Destination, and Service; only specified fields are translated.

The gateway's routing table and ARP behavior determine whether translated addresses are reachable; verify with ip route and ARP tables.

Identity mappings expire after a configured timeout; stale mappings can grant access to the wrong user after IP reuse.

The PDP can run on the gateway or management; identity sharing uses a trusted channel between PDPs.

Rules using 'User' or 'Access Role' require Identity Awareness; without it, identity-based rules do not match.

Guest and Unknown identities can be handled by dedicated rules placed before general allow rules.

Application Control can match on application, category, risk level, and characteristics (e.g., 'file sharing').

Custom applications can be defined by signature or by URL/port for internal or unsupported apps.

Application Control actions are applied on Accept rules; a Block action prevents the session and logs it.

Encrypted traffic classification depends on HTTPS Inspection; without it, only limited metadata is visible.

URL Filtering can block by category, by specific URL, or allow exceptions; exceptions must be ordered correctly.

HTTPS Inspection requires a CA certificate trusted by clients; bypass lists exclude sensitive sites from inspection.

Anti-Virus and Anti-Bot profiles are attached to rules; scanning depth and file-size limits are configurable.

Content Security logs record the blade, file name, verdict, and action for each inspected object.

Threat Prevention profiles can be applied per rule or per gateway; the profile determines which protections are active.

IPS protections can be overridden per profile (Prevent/Detect/Inactive) and by severity.

SmartEvent correlation rules combine multiple logs into a single event; reactions can run scripts or send alerts.

Log indexing and forwarding to external SIEM are configured on the log server; retention is set per log server.

fw monitor uses inspection points i (pre-inbound), I (post-inbound), o (pre-outbound), O (post-outbound); filters use -e expressions.

cpview shows per-blade counters and connection tables; use it to spot drops and resource exhaustion.

cpinfo -y all reports installed hotfixes and versions; useful before opening a support case.

Policy install failures often trace to SIC trust, license, or version mismatch; check the install log and fw stat.

The management server's object database is the source of truth; gateways receive a compiled policy, not the raw rule base.

A Standby management server must be synchronized before promotion; unsynchronized promotion risks data loss.

SIC trust is verified by fingerprint comparison; mismatched fingerprints block policy installation and log transfer.

Contracts (Support, Application Control, URL Filtering, Threat Prevention) gate update services and blade availability.

The Web API uses HTTPS and returns JSON; authentication yields a session ID and a CSRF token for subsequent calls.

Object names are unique per type; renaming an object updates references across the rule base.

Deleted objects referenced by rules are flagged; the rule base cannot be installed with dangling references.

SmartConsole version must be compatible with the management server version; mismatch limits available features.

The cleanup rule is implicit and drops unmatched traffic; its action can be logged for visibility.

Inline layers allow per-rule sub-policies; the parent rule's action applies after the inline layer evaluates.

Rule 'Install On' targets scope enforcement; a rule installed on one gateway does not affect others.

Time objects restrict rule matching to schedules; outside the schedule the rule does not match.

NAT is applied before the security rule base evaluates for outbound flows; logs reflect translated addresses.

Hide NAT uses port overloading; Static NAT preserves ports and is used for inbound published services.

Manual NAT rules are ordered independently of security rules; place specific rules above general ones.

Verify NAT with fw monitor and logs showing original and translated addresses.

AD Query requires access to domain controller security event logs; permissions must allow reading those events.

Identity Collector uses an agent on the domain controller and scales to large environments.

Captive Portal can be transparent or explicit; it authenticates users before granting access.

Identity mappings are per-IP; IP reuse after timeout can misattribute access if timeouts are too long.

Application signatures are updated via the update service; stale signatures misclassify new applications.

Risk levels (low/medium/high/critical) let rules block by risk rather than by name.

Application Control can limit bandwidth for matched applications when the Limit action is available.

Custom applications cover internal or unclassified apps by signature or URL/port.

URL categories are updated by the URL Filtering update service; expired contracts stop updates.

HTTPS Inspection requires client trust of the gateway CA; bypass lists exclude sensitive sites.

Content Security profiles attach to Accept rules; no profile means no content inspection.

Anti-Bot detects command-and-control traffic; Anti-Virus scans files for malware.

Threat Emulation sandboxes suspicious files; Threat Extraction sanitizes and delivers immediately.

IPS protections have severities; profiles set Prevent/Detect/Inactive per protection.

SmartEvent correlates logs into events; reactions can alert or run scripts.

Log retention and forwarding are configured per log server; plan storage accordingly.

fw monitor inspection points i/I/o/O show pre/post-NAT and pre/post-inspection traffic.

cpstat and cpview report gateway health; cpinfo collects diagnostics for support.

migrate export/import move the database; cpbackup backs up the full system.

Policy install failures often trace to SIC, license, or version mismatch; check install log and fw stat.