Custom Snort 3 Intrusion Policies for Access Control

PDF

Custom Snort 3 Intrusion Policies for Access Control

How policies examine traffic for intrusions

Updated: February 4, 2026

Want to summarize with AI?

Log in

Describes how the system analyzes traffic through network analysis and intrusion prevention phases in access control deployments.

When the system analyzes traffic as part of your access control deployment, the network analysis (decoding and preprocessing) phase occurs before and separately from the intrusion prevention (intrusion rules and advanced settings) phase.

Summary

The key components involved in examining traffic for intrusions are:

  • Security Intelligence: Performs initial traffic filtering and blocking

  • SSL policy: Handles encrypted traffic inspection and decryption

  • Network analysis policies: Conduct decoding and preprocessing of traffic

  • Access control rules: Determine which policies to apply to traffic

  • Intrusion policies: Examine traffic for security threats and intrusions

  • File policies: Analyze files for malware and threats

  • Network discovery policy: Passively inspects packets for network mapping

Workflow


Diagram of traffic flow as described above, showing that preprocessing by network analysis policies occurs after SSL inspection, but before access control rules invoke intrusion policies.

These stages describe how the system examines traffic for intrusions in an inline deployment:

  1. The system processes traffic through multiple policy layers in a specific order, with network analysis and intrusion policy selection phases highlighted in the deployment. In an inline deployment (that is, where relevant configurations are deployed to devices using routed, switched, or transparent interfaces, or inline interface pairs), the system can block traffic without further inspection at almost any step in the illustrated process. Security Intelligence, the SSL policy, network analysis policies, file policies, and intrusion policies can all either drop or modify traffic. Only the network discovery policy, which passively inspects packets, cannot affect the flow of traffic.
  2. At each step of the process, a packet could cause the system to generate an event. Intrusion and preprocessor events (sometimes referred to collectively as intrusion events) are indications that a packet or its contents may represent a security risk.
    Tip

    The diagram does not reflect that access control rules handle encrypted traffic when your SSL inspection configuration allows it to pass, or if you do not configure SSL inspection. By default, the system disables intrusion and file inspection of encrypted payloads. This helps reduce false positives and improve performance when an encrypted connection matches an access control rule that has intrusion and file inspection configured.

  3. Note that for a single connection, although the system selects a network analysis policy before an access control rule as shown in the diagram, some preprocessing (notably application layer preprocessing) occurs after access control rule selection. This does not affect how you configure preprocessing in custom network analysis policies.

Decoding, normalizing, and preprocessing: Network analysis policies

Without decoding and preprocessing, the system cannot appropriately evaluate traffic for intrusions because protocol differences would make pattern matching impossible. Network analysis policies govern these traffic-handling tasks

  • after traffic is filtered by Security Intelligence,

  • after encrypted traffic is decrypted by an optional SSL policy, and

  • before traffic can be inspected by file or intrusion policies

A network analysis policy governs packet processing in phases. First the system decodes packets through the first three TCP/IP layers, then continues with normalizing, preprocessing, and detecting protocol anomalies:

  • The packet decoder converts packet headers and payloads into a format that can be easily used by the inspectors and later, intrusion rules. Each layer of the TCP/IP stack is decoded in turn, beginning with the data link layer and continuing through the network and transport layers. The packet decoder also detects various anomalous behaviors in packet headers.

  • In inline deployments, the inline normalization preprocessor reformats (normalizes) traffic to minimize the chances of attackers evading detection. It prepares packets for examination by other inspectors and intrusion rules, and helps ensure that the packets the system processes are the same as the packets received by the hosts on your network.

  • Various network and transport layers inspectors detect attacks that exploit IP fragmentation, perform checksum validation, and perform TCP and UDP session preprocessing.

    Note that some advanced transport and network inspector settings apply globally to all traffic handled by the target devices of an access control policy. You configure these in the access control policy rather than in a network analysis policy.

  • Various application-layer protocol decoders normalize specific types of packet data into formats that the intrusion rules engine can analyze. Normalizing application-layer protocol encodings allows the system to effectively apply the same content-related intrusion rules to packets whose data is represented differently, and to obtain meaningful results.

  • The Modbus, DNP3, CIP, and s7commplus SCADA inspectors detect traffic anomalies and provide data to intrusion rules. Supervisory Control and Data Acquisition (SCADA) protocols monitor, control, and acquire data from industrial, infrastructure, and facility processes such as manufacturing, production, water treatment, electric power distribution, airport, and shipping systems.

  • Several inspectors allow you to detect specific threats, such as Back Orifice, portscans, SYN floods and other rate-based attacks.

    Note that you configure the sensitive data inspector, which detects sensitive data such as credit card numbers and Social Security numbers in ASCII text, in intrusion policies.

Note

When TLS Server Identity is disabled, Snort 3 does not perform SNI mismatch detection. It only evaluates the SNI in the Client Hello packet and bypasses the validation of the certificate's Common Name (CN) in the Server Hello packet.

In a newly created access control policy, one default network analysis policy governs preprocessing for all traffic for all intrusion policies invoked by the same parent access control policy. Initially, the system uses the Balanced Security and Connectivity network analysis policy as the default, but you can change it to another system-provided or custom network analysis policy. In a more complex deployment, advanced users can tailor traffic preprocessing options to specific security zones, networks, and VLANs by assigning different custom network analysis policies to preprocess matching traffic.

Note

For an access control policy with rule action as Trust and a prefilter rule with action as Fastpath with logging options disabled, you will observe that the end-of-flow events are still generated in the system. The events are not visible on the management center event pages.

Access control rules: Intrusion policy selection

Intrusion policy selection is a traffic evaluation process that—

  • evaluates traffic after initial preprocessing using access control rules,

  • applies matching access control rule to handle traffic through monitor, trust, block, or allow actions,

  • inspects allowed traffic for discovery data, malware, prohibited files, and intrusions in that order, and

  • handles non-matching traffic using the access control policy's default action.

In most cases, the first access control rule that a packet matches is the rule that handles that traffic; you can monitor, trust, block, or allow matching traffic.

Traffic evaluation process

When you allow traffic with an access control rule, the system can inspect the traffic for discovery data, malware, prohibited files, and intrusions, in that order. Traffic not matching any access control rule is handled by the access control policy's default action, which can also inspect for discovery data and intrusions.

Note

All packets, regardless of which network analysis policy preprocesses them, are matched to configured access control rules, making them potentially subject to inspection by intrusion policies in top-down order.

The diagram in How policies examine traffic for intrusions shows the flow of traffic through a device in an inline, intrusion prevention and AMP for Networks deployment—

  • Access Control Rule A allows matching traffic to proceed. The traffic is then inspected for discovery data by the network discovery policy, for prohibited files and malware by File Policy A, and then for intrusions by Intrusion Policy A.

  • Access Control Rule B also allows matching traffic. However, in this scenario, the traffic is not inspected for intrusions (or files or malware), so there are no intrusion or file policies associated with the rule. Note that by default, traffic that you allow to proceed is inspected by the network discovery policy; you do not need to configure this.

  • In this scenario, the access control policy's default action allows matching traffic. The traffic is then inspected by the network discovery policy, and then by an intrusion policy. You can (but do not have to) use a different intrusion policy when you associate intrusion policies with access control rules or the default action.

The example in the diagram does not include any blocking or trusting rules because the system does not inspect blocked or trusted traffic.

Intrusion inspection: Intrusion policies, rules, and variable sets

Intrusion inspection is a security mechanism that

  • uses intrusion policies to govern how the system inspects traffic for security violations and can block or alter malicious traffic in inline deployments

  • employs intrusion and preprocessor rules to analyze network traffic against specified criteria and detect attempts to exploit vulnerabilities, and

  • utilizes variable sets to define values commonly used in intrusion rules for identifying source and destination IP addresses and ports.

Intrusion and inspector rules

An intrusion rule is a specified set of keywords and arguments that detects attempts to exploit vulnerabilities on your network; the system uses an intrusion rule to analyze network traffic to check if it matches the criteria in the rule. The system compares packets against the conditions specified in each rule and, if the packet data matches all the conditions specified in a rule, the rule triggers.

The system includes these types of rules created by Cisco Talos Intelligence Group (Talos):

  • shared object intrusion rules, which are compiled and cannot be modified, except for rule header information such as source and destination ports and IP addresses

  • standard text intrusion rules, which can be saved and modified as new custom instances of the rule.

  • preprocessor rules, which are rules associated with inspectors and packet decoder detection options in the network analysis policy. You cannot copy or edit inspector rules. Most inspector rules are disabled by default; you must enable them to use inspectors to generate events and, in an inline deployment, drop offending packets.

When the system processes packets according to an intrusion policy, first a rule optimizer classifies all activated rules in subsets based on criteria such as: transport layer, application protocol, direction to or from the protected network, and so on. Then, the intrusion rules engine selects the appropriate rule subsets to apply to each packet. Finally, a multi-rule search engine performs three different types of searches to determine if the traffic matches the rule:

  • The protocol field search looks for matches in particular fields in an application protocol.

  • The generic content search looks for ASCII or binary byte matches in the packet payload.

  • The packet anomaly search looks for packet headers and payloads that, rather than containing specific content, violate well-established protocols.

In a custom intrusion policy, you can tune detection by enabling and disabling rules, as well as by writing and adding your own standard text rules. You can also use Cisco recommendations to associate the operating systems, servers, and client application protocols detected on your network with rules specifically written to protect those assets.

Note

When there are insufficient packets to process specific traffic against a block rule, the system continues to evaluate the remaining traffic against other rules. If any of the remaining traffic matches a rule which is set to block, then the session is blocked. However, if the system analyses the remaining traffic to be passed, then the traffic status shows pending on the rule which is stuck for want of complete packets.

Variable Sets

Whenever the system uses an intrusion policy to evaluate traffic, it uses an associated variable set. Most variables in a set represent values commonly used in intrusion rules to identify source and destination IP addresses and ports. You can also use variables in intrusion policies to represent IP addresses in rule suppressions and dynamic rule states.

The system provides a single default variable set, which is comprised of predefined default variables. Most system-provided shared object rules and standard text rules use these predefined default variables to define networks and port numbers. For example, the majority of the rules use the variable $HOME_NET to specify the protected network and the variable $EXTERNAL_NET to specify the unprotected (or outside) network. In addition, specialized rules often use other predefined variables. For example, rules that detect exploits against web servers use the $HTTP_SERVERS and $HTTP_PORTS variables.

Tip

Even if you use system-provided intrusion policies, Cisco strongly recommends that you modify key default variables in the default set. When you use variables that accurately reflect your network environment, processing is optimized and the system can monitor relevant systems for suspicious activity. Advanced users can create and use custom variable sets for pairing with one or more custom intrusion policies.

If you are creating a custom variable set, do not use a number as the first character in a custom variable set name (for example, 3Snort). This will cause Snort 3 validation to fail when you deploy a configuration to Firewall Threat Defense firewall on the Firewall Management Center.

Intrusion event generation

Intrusion event generation is a security mechanism that:

  • identifies possible intrusions through packet decoding, preprocessing, and rules engine analysis,

  • generates intrusion or preprocessor events (sometimes collectively called intrusion events) when threats are detected, and

  • transmits events from managed devices to the Firewall Management Center for aggregated analysis and network asset protection.

Event composition and data collection

Each intrusion event in the database includes an event header and contains information about the event name and classification; the source and destination IP addresses; ports; the process that generated the event; and the date and time of the event, as well as contextual information about the source of the attack and the target. For packet-based events, the system also logs a copy of the decoded packet header and payload for the packet or packets that triggered the event.

As the database accumulates intrusion events, you can begin your analysis of potential attacks. The system provides you with the tools you need to review intrusion events and evaluate whether they are important in the context of your network environment and your security policies.

Event generation scenarios

The packet decoder, the preprocessors, and the intrusion rules engine can all cause the system to generate an event. For example:

  • If the packet decoder (configured in the network analysis policy) receives an IP packet that is less than 20 bytes, which is the size of an IP datagram without any options or payload, the decoder interprets this as anomalous traffic. If, later, the accompanying decoder rule in the intrusion policy that examines the packet is enabled, the system generates a inspector event.

  • If the IP defragmentation preprocessor encounters a series of overlapping IP fragments, the inspector interprets this as a possible attack and, when the accompanying inspector rule is enabled, the system generates a inspector event.

  • Within the intrusion rules engine, most standard text rules and shared object rules are written so that they generate intrusion events when triggered by packets.