AWS Network Firewall stateful rule groups

Question

Hi there,

I'm currently investigating the use of the "suricata-like" rules in AWS NF. When the default order is used everything works more or less as expected. However when the strict order is used, I fail to understand what is going on. For example with two rules such as

```
drop http any any -> $WWW_AWS_NET 80 (msg:"HTTP GET"; flow:established, to_server; http.method; content:"GET"; sid:403; rev:1;)
pass tcp any any -> $WWW_AWS_NET 80 (msg:"HTTP"; sid:404; rev:1;)
```

I would expect TCP HTTP traffic to flow through the FW except if being an HTTP GET. However  the actual behavior is that everything goes through as if pass rules were evaluated before drop rules (just like in the default order). So my question: Am I missing something with these two rules or does "the rules in each rule group are processed in the order in which they're defined" really mean "as long as they belong to the same "pass", "drop", "alert" group" ?

Thanks !

Paul

Sheng Chen · Answer

Hi Paul, your understanding of the strict rule order is correct. *" 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."*

https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-rule-evaluation-order.html#suricata-strict-rule-evaluation-order

You might want to check other rule variable such as IP sets (*HOME_NET*) and make sure the rule is applied to the correct flow.

AWS-User-5786690 · Answer

Thanks for your answer. The problem was actually coming from my testing tool that was generating traffic not recognized as HTTP.
Paul

Tom · Answer

Hi
I know its to late but let me post the following link for others that's face such problems

https://docs.aws.amazon.com/en_en/network-firewall/latest/developerguide/troubleshooting-rules.html#troubleshoot-rules-strict-ordering-rule-order
You need to add "flow:to_server" to make it running as you expect.

Each TCP application communication starts with some standard TCP communications to establish the connection.
This initial communication is needed to establish the application level and you should not block this.
In your case the firewall detect the TCP initiation traffic and allow the whole firewall connection (no future checks on application level)
flow:to_server fix this and additionally roles on application level will work.

AWS Network Firewall stateful rule groups

Relevant content