1 Answer
- Newest
- Most votes
- Most comments
1
While I would need to test and debug as to why your current rule isn't functional, what you can do for the time being is using an ALLOW list design.
If you decide to use default order, the stateful rule engine will evaluate pass rules before it does so drop rules. You can create an implicit drop of everything and then create a pass for any to and from the proxy.
For the time being this would accomplish the same as what you're attempting to accomplish with your rule.
answered a year ago
Relevant content
- Accepted Answerasked 3 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 4 months ago
- AWS OFFICIALUpdated 2 years ago
Hi, for some reason, we can't utilize the default order, because our firewall policy also associates with AWS-managed rule groups and we want to let aws managed rule group inspect the packages before hitting our custom firewall rule above. If we utilize the default order and create allow list design then it will by pass all aws managed rule groups cause pass rule will be evaluated first.
So testing your rule and looking into documentation, it seems the problem becomes obvious with this one Warning within the Suricata documentation: https://suricata.readthedocs.io/en/suricata-6.0.9/rules/intro.html#direction
"There is no ‘reverse’ style direction, i.e. there is no <-."
Your rule, utilizing <>, means that traffic from Proxy would match the rule. We can think about it as such: drop ip !$PROXY_IPS any -> any any drop ip any any -> !$PROXY_IPS any (This is blocking your traffic)
Changing <> into -> should solve your problem.