Managing evaluation order for Suricata compatible rules in AWS Network Firewall

You can configure and manage the evaluation order of the rules in your Suricata compatible 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 it 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 Stateful rules examples: manage rule evaluation order.

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

• Suricata.yaml: Action-order

• Meta Keywords: priority

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

If you have rules that match application layer data, such as those that evaluate HTTP headers, a default drop action might trigger earlier than you want. This can happen when the data that your rules match against spans multiple packets, because a default drop action can apply to a single packet. For this case, don't choose any default drop action and instead use drop rules that are specific to the application layer.

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 AWS Network Firewall.