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

Reply
Highlighted
L2 Linker

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

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

Highlighted
Cyber Elite

@danielmartins,

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. 

Highlighted
L2 Linker

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

 

Highlighted
L6 Presenter

@danielmartins,

 

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



Mayur
Highlighted
L2 Linker

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

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!