スキップしてコンテンツを表示

AWS Network Firewall stateful rule groups

0

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

3回答
0

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
エキスパート

回答済み 5年前

0

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

回答済み 4年前

0

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.

回答済み 2年前

ログインしていません。 ログイン 回答を投稿する。

優れた回答とは、質問に明確に答え、建設的なフィードバックを提供し、質問者の専門分野におけるスキルの向上を促すものです。

関連するコンテンツ