5.4 Intrusion Prevention System (IPS)

What IPS Does

The Intrusion Prevention System (IPS) blade inspects allowed traffic for attack signatures. Where Access Control decides if a connection is permitted and Application Control decides what application is running, IPS decides whether the content of that connection constitutes an attack against the client or server.

IPS is signature-based. Each protection in the IPS database describes a pattern of traffic that indicates a known attack: a buffer-overflow attempt against a specific service, a SQL injection pattern in HTTP input, a malformed DNS response, an exploit against a known CVE. The IPS database is maintained by Check Point research teams and distributed via ThreatCloud updates.

When the gateway sees traffic that matches a protection, the configured action fires. IPS actions are:

• Drop — silently drop the packet (or the connection).
• Reject — drop and send a reset to the source.
• Activate — log and continue (used for monitoring / IDS-style deployment).
• Ask — prompt the user (less common in IPS, more common in Application Control).

Protections and Signatures

IPS terminology is important for the CCSA:

• A protection is a single detect-and-prevent rule in the IPS database. There are thousands of protections in a current R82 IPS database.
• Each protection is tagged with a Protection Type (e.g., HTTP, SMTP, DNS, SQL, OS) and a severity.
• Each protection has a Confidence Rating (how sure Check Point is that this is a real attack) and a Performance Impact rating (how much enabling this protection costs in gateway throughput).

The Confidence Rating and Performance Impact rating together guide whether a protection should be enabled in your environment. High-confidence, low-impact protections are safe to enable everywhere. Low-confidence or high-impact protections require careful testing.

Performance Impact Levels

IPS protections carry a Performance Impact rating, typically Low, Medium, High (and in some interfaces a numerical scale). The rating reflects how much inspecting that protection costs the gateway. A protection that requires deep packet reassembly, full protocol parse, or multiple match passes costs more than a simple pattern match.

The built-in TP profiles use these ratings to decide which protections are enabled:

A common CCSA scenario: a gateway is deployed on a saturated link and IPS is causing packet loss. The recommended response is to step down from Strict to Optimized, or to disable specific High-impact protections in a custom profile, rather than disabling IPS entirely.

Protocol Coverage and Exception Handling

IPS protections are grouped by protocol — HTTP, HTTPS (with HTTPS Inspection), SMTP, DNS, FTP, SMB, SQL, and so on. Within each protocol, protections cover both client-side and server-side attacks. Client-side protections detect attacks against the user's browser or app; server-side protections detect attacks against the destination service.

Administrators can create IPS Exceptions to suppress a specific protection for a specific source, destination, or service. Exceptions are useful when a legitimate application triggers a false positive on a known protection. The exception does not disable the protection globally — it disables it for the named scope. CCSA questions test the concept of exceptions and the discipline of scoping them narrowly.

IPS in the Policy

IPS is enabled through a TP profile. Inside the profile, the IPS section lets you choose which protections are active (directly, or via the profile's built-in selection), set the action per protection (Drop, Reject, Activate, Ask), and define exceptions for specific sources/destinations.

When a TP rule attaches that profile to a connection, IPS runs the active protections against the connection's content. The first matching protection determines the action.

The "Activate" Action and IDS Mode

Setting all IPS protections to Activate effectively turns the gateway into an IDS — it logs attacks but does not block them. This is useful for a learning period after deploying IPS in a new environment. The standard rollout pattern is: deploy IPS in Activate for a week, review logs for false positives, create exceptions, then switch to Drop. CCSA scenarios sometimes describe this rollout pattern and ask which action corresponds to the IDS-style phase. The answer is Activate.

IPS Update Mechanism

IPS protections are updated through ThreatCloud. Updates can be scheduled or run manually from SmartConsole. Staying current is important: new CVEs lead to new protections, and a gateway running an old IPS database is blind to recent attacks. The CCSA expects you to know that IPS updates come from ThreatCloud (the same source as Application Control and URLF updates) and that the gateway can install them on a schedule.

What IPS Does Not Do

IPS does not detect malware by file hash — that is Anti-Virus. IPS does not sandbox unknown files — that is Threat Emulation. IPS does not detect C&C communication — that is Anti-Bot. IPS detects attack patterns in traffic, not bad files or bad destinations. Keeping this scope clear is essential on the CCSA, because many scenario questions hinge on which blade owns which detection.

Common CCSA Scenarios

Typical IPS questions:

• Identify the action that logs but does not block (Activate).
• Identify the source of IPS updates (ThreatCloud).
• Choose the right profile for a saturated link (drop from Strict to Optimized).
• Recognize the difference between Confidence Rating and Performance Impact.
• Identify which blade owns which threat class (IPS for attack patterns, AV for malware files, AB for C&C).