Behaviour of NAT and Security Rules along with intrazone -default rule.

[mr_almeida]

Hi Gang,

Still getting grips to everything so would love your help in understanding the behaviour of traffic when it is NATed and allowed. 

The Scenario: 

• Zones: outside and inside
  A DNAT rule from outside-to-outside that NATs 1.1.1.1:22 which translates to 192.168.1.1:22
  A security policy that from outside-to-inside traffic for 1.1.1.1:22

Result:

• Any other traffic destined for 1.1.1.1 but not matching port 22 matches the intrazone-default rule. This results in traffic being allowed. However, traffic will time-out as there is nothing on that public address. 

Questions:

1. Is this the expected behaviour of the firewall?
2. Why is traffic allowed from ports which we did not specifically define in the NAT and alow in the security rule?
3. Should I be worried that traffic other than specified in the NAT and security policy is being allowed?
4. How best to block this behaviour? I guess we'd need to create a deny security rule for each allow rule to prevent happening? 

Thank you a bunch!!!

Daniel

[BPry]

@mr_almeida,

Questions:

1. 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. 
2. 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.
3. 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.
4. 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. 

[mr_almeida]

Thanks for the reply @BPry .

The intrazone-default rule is useful in that as I am not using a complete zero-trust design, so for it to automatically alow traffic in the same zones is most useful like inside-to-inside but not as useful say outside-to-outside. 

Yes, I see that creating individual rules is not efficient when you can create a security rule such as outside-to-outside block any service and port (since the traffic is already explicitly permitted would be above this block any rule).

I'd essentially create however many explicitly defined intrazone blocking rules for zones of which traffic I do not want to hit the intrazone-default rule.

Thank you for taking the time to reply and clarify! Hopefully, I've made sense with the above!

Dan

[SutareMayur]

@mr_almeida,

I think, your Security Policy  & NAT should be like this -

A DNAT rule from outside-to-inside that NATs 1.1.1.1:22 which translates to 192.168.1.1:22
A security policy that from outside-to-inside traffic for 1.1.1.1:22 - Same as you have written

With this, i dont think if it will match default intrazone policy. When you're putting DNAT for outside-to-outside zone, so it is matching intrazone policy as firewall is considering destination zone as outside due to wrong DNAT policy. This is because in packet processing, firewall evaluates NAT first. If you make changes in DNAT rule as given above, it will match correct security policy written by you.

Hope it helps!

Mayur

Mayur

[mr_almeida]

Thank you for your response @SutareMayur .

I don't think that NAT will work? NAT works on PRE-NAT public addresses and thus their PRE-NAT zones. Only the security policy works with the true final destination zone i.e. inside once the lookup is performed

Daniel