@mr_almeida,
Questions:
Is this the expected behaviour of the firewall? Yes. Anything traversing the same zone is, by default, allowed. So if you don't want anything to hit your intrazone-default security entry, you would simply create a catch-all untrust/untrust security entry right above it with the application and service set to any with the action of deny.
Why is traffic allowed from ports which we did not specifically define in the NAT and alow in the security rule? Because of the intrazone-default security rulebase entry. If you haven't specifically created a rulebase entry denying the traffic or overrode the intrazone-default action to deny, the traffic will be allowed. This is the same for untrust/untrust traffic or trust/trust traffic. Anything in the same zone, traversing the same zone, will be allowed by default.
Should I be worried that traffic other than specified in the NAT and security policy is being allowed? Depending on network configuration and rulebase configuration it could be an issue. If you are concerned about the behavior, simply create the catch-all as mentioned above.
How best to block this behaviour? I guess we'd need to create a deny security rule for each allow rule to prevent happening? Creating a deny security entry for each would be silly. Simply create a policy that says anything from untrust/untrust is denied at the bottom of your security rulebase. Doing so will prevent the default intrazone-default security entry from matching and the traffic will be denied unless you've specifically allowed it. Another option would be to simply override the intrazone-default entry to 'deny', but you'd want to enable logging and verify that you aren't seeing any other intrazone traffic that actually needs to be allowed for things to function.
This default behavior trips up a lot of people when they first start working with a zone based firewall, but it's fairly standard across all zone based firewall vendors. If you have a proper DMZ setup and handle your NAT entries correctly it's not a big issue, but it has certainly caused some people to unintentionally expose services because they didn't properly account for the behavior.
... View more