Logging for Blocked Connections

You can log blocked connections, which includes traffic matching the following rules and actions:

  • Tunnel rules—Block

  • Prefilter rules—Block

  • Prefilter default action—Block all tunnel traffic

  • Security Intelligence—Block lists not set to Monitor (also generates a Security Intelligence event)

  • SSL rules—Block and Block with reset

  • SSL default action—Block and Block with reset

  • Access control rules—Block, Block with reset, and Interactive Block

  • Access control default action—Block All Traffic

Only devices deployed inline (that is, using routed, switched, or transparent interfaces, or inline interface pairs) can block traffic. Because blocked connections are not actually blocked in passive deployments, the system may report multiple beginning-of-connection events for each blocked connection.

Caution

Logging blocked TCP connections during a Denial of Service (DoS) attack can affect system performance and overwhelm the database with multiple similar events. Before you enable logging for an Block rule, consider whether the rule monitors traffic on an Internet-facing interface or other interface vulnerable to DoS attack.

Beginning vs End-of-Connection Logging for Blocked Connections

When you log a blocked connection, how the system logs it depends on why the connection was blocked; this is important to keep in mind when configuring correlation rules based on connection logs:

  • For SSL rules and SSL policy default actions that block encrypted traffic, the system logs end-of-connection events. This is because the system cannot determine if a connection is encrypted using the first packet in the session.

  • For other blocking actions, the system logs beginning-of-connection events. Matching traffic is denied without further inspection.

Logging Bypassed Interactive Blocks

Interactive blocking access control rules, which cause the system to display a warning page when a user browses to a prohibited website, allow you to configure end-of-connection logging. This is because if the user clicks through the warning page, the connection is considered a new, allowed connection which the system can monitor and log.

Therefore, for packets that match an Interactive Block or Interactive Block with Reset rule, the system can generate the following connection events:

  • A beginning-of-connection event when a user’s request is initially blocked and the warning page is displayed; this event has an associated action of Interactive Block or Interactive Block with Reset

  • Multiple beginning- or end-of-connection events if the user clicks through the warning page and loads the originally requested page; these events have an associated action of Allow and a reason of User Bypass

    The following figure shows an example of an interactive block followed by allow.