View a markdown version of this page

Actions and scopes - Amazon Network Firewall
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).

Actions and scopes

Every firewall rule begins with an action and an explicit scope, written as action:scope (for example, accept:flow or drop:packet). Two rules govern which combinations are valid:

  • The primary action must be accept, drop, reject, rejectdst, or rejectboth. rejectsrc is accepted as a synonym for reject. A firewall rule can't use pass or alert as its primary action. (pass is available only as a secondary action that bypasses the IPS engine, and alert only as a modifier that adds logging. For the IPS bypass, see Bypassing the IPS engine for accepted traffic.)

  • The scope is mandatory. A firewall rule that omits the scope is rejected.

Each action supports a different set of scopes, and the hook further restricts which of those scopes are valid. The following table shows the valid scopes for each action. For what each scope means, see Firewall engine actions and scopes.

Action Valid scopes Notes
accept flow, tx, hook, packet The only action that supports the tx and hook scopes. Use accept:flow to carry a whole connection forward on a match.
drop flow, packet The hook and tx scopes aren't valid for drop.
reject flow, packet Same scopes as drop. reject blocks the traffic and also sends a TCP reset to the client.
rejectdst flow, packet Same scopes as reject. rejectdst blocks the traffic and sends a TCP reset to the destination (modeled rule value REJECT_DST).
rejectboth flow, packet Same scopes as reject. rejectboth blocks the traffic and sends a TCP reset to both the client and the destination (modeled rule value REJECT_BOTH).

The hook adds one more restriction: the packet scope is valid only at a packet hook (such as tcp:all) or at an application-layer hook for a protocol that runs over UDP (such as a DNS hook). The packet scope isn't valid at an application-layer hook for a protocol that runs only over TCP, such as a TLS or HTTP/2 hook—at those hooks, use flow, tx, or hook instead. The following table summarizes the valid action-and-scope combinations for each kind of hook.

Action and scope Packet hook (for example, tcp:all) TCP application hook (for example, tls:client_hello) UDP application hook (for example, dns:request_complete)
accept:flow, accept:hook, accept:tx Valid Valid Valid
accept:packet Valid Not valid Valid
drop:flow, reject:flow Valid Valid Valid
drop:packet, reject:packet Valid Not valid Valid
Any action with no scope Not valid Not valid Not valid
pass or alert as the primary action Not valid Not valid Not valid
Note

The accept-prior-hooks form of a hook, written with a leading < (for example, tls:<client_hello), is valid only with accept:flow, accept:tx, or accept:hook. You can't use it with a drop or reject action. For more information, see Accepting prior hooks automatically.

For more about how the underlying actions and action scopes behave, see Firewall design in the Suricata User Guide.