Evaluation order for stateful rule groups - Amazon Network Firewall
Action orderStrict evaluation order
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Evaluation order for stateful rule groups

All of your stateful rule groups are provided to the rule engine as Suricata compatible strings. Suricata can evaluate stateful rule groups by using the default rule group ordering method, or you can set an exact order using the strict ordering method. We recommend that you use strict order because it lets you specify the exact order that you'd like the stateful engine to evaluation your rules. The settings for your rule groups must match the settings for the firewall policy that they belong to.

Action order

If your firewall policy is set up to use action order rule group ordering, the action order by which Suricata evaluates stateful rules is determined by the following settings, listed in order of precedence:

  1. The Suricata action specification. This takes highest precedence.

    Actions are processed in the following order:

    1. pass

    2. drop

    3. reject

    4. alert

    Note

    If a packet within a flow matches a rule containing pass action, then Suricata doesn't scan the other packets in that flow and passes the unscanned packets.

    For more information about the action specification, see Suricata.yaml: Action-order in the Suricata User Guide.

  2. The Suricata priority keyword. Within a specific action group, you can use the priority setting to indicate the processing order. By default, Suricata processes from the lowest numbered priority setting on up. The priority keyword has a mandatory numeric value ranging from 1 to 255. Note that the priority keyword is only valid using the default action order.

    For more information about priority, see Suricata.yaml: Action-order in the Suricata User Guide.

For example, Suricata evaluates all pass rules before evaluating any drop, reject, or alert rules by default, regardless of the value of priority settings. Within all pass rules, if priority keywords are present, Suricata orders the processing according to them.

The protocol layer does not impact the rule evaluation order by default. If you want to avoid matching against lower-level protocol packets before higher-level application protocols can be identified, consider using the flow keyword in your rules. This is needed because, for example, a TCP rule might match on the first packet of a TCP handshake before the stateful engine can identify the application protocol. For information about the flow keyword, see Flow Keywords.

For examples of default rule order management, see Managing rule evaluation order.

For additional information about evaluation order for stateful rules, see the following topics in the Suricata User Guide:

Strict evaluation order

If your firewall policy is set up to use strict ordering, Network Firewall allows you the option to manually set a strict rule group order. With strict ordering, the rule groups are evaluated by order of priority, starting from the lowest number, and the rules in each rule group are processed in the order in which they're defined.

When you choose Strict for your rule order, you can choose one or more Default actions. Note that this does not refer to default action rule ordering, but rather, to the default actions that Network Firewall takes when following your strict, or exact, rule ordering. The default actions are as follows:

Drop actions:

Choose none or one. You can't choose both.

  • Drop all – Drops all packets.

  • Drop established – Drops only the packets that are in established connections. This allows the layer 3 and 4 connection establishment packets that are needed for the upper-layer connections to be established, while dropping the packets for connections that are already established. This allows application-layer pass rules to be written in a default-deny setup without the need to write additional rules to allow the lower-layer handshaking parts of the underlying protocols.

    Choose this option when using strict order for your own domain list rule groups because Network Firewall requires an established connection in order to evaluate whether to pass or drop the packets for domain lists.

    For other protocols, such as UDP, Suricata considers the connection established only after seeing traffic from both sides of the connection.

Alert actions:

Choose none, one, or both.

  • Alert all - Logs an ALERT message on all packets. This does not drop packets, but alerts you to what would be dropped if you were to choose Drop all.

  • Alert established - Logs an ALERT message on only the packets that are in established connections. This does not drop packets, but alerts you to what would be dropped if you were to choose Drop established.

For more information about logging network traffic, see Logging network traffic from Amazon Network Firewall.