Untrust to Untrust - Allow

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

Untrust to Untrust - Allow

L4 Transporter

I was working at a customer site and noticed the customer's last rule before their "Catch-All - Deny" rule was  "Untrust - Untrust Allow". It was a universal rule with source zone untrust  destination zone untrust set to allow. When I asked why they had this rule, the response was "By default,  the firewall comes with a default intrazone allow rule, which is the same thing"

 

I personally would never set up this rule. Since they were using VPNs, I suggested replacing that with a VPN rule untrust -> untrust, allowing applications for ike, ipsec and gp.  In the end, they declined.

 

Just wondering your opinions on this?

1 accepted solution

Accepted Solutions

well their untrust untrust allow does not do anything in it's own as the default policy would already do what it does (allow intrazone traffic)

 

you could certainly rebuild that policy to only allow the applications you want, like ike and ipsec, and then set the default rule to drop instead of allow, or create a deny all rule for untrust at the end

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

View solution in original post

11 REPLIES 11

L6 Presenter

I always make 'default drop' rule which drops everything to override intrazone rule.

Cyber Elite
Cyber Elite

by default there is indeed an intrazone allow all policy which will only allow session inside the same zone

 

there's 2 common uses for this policy (with the second one not being my favorite, but it's there as an FYI)

 

first, you will allow connections to the firewall interface, which won't do anything and get dropped anyway if a service is not attached to a socket (but it facilitates VPNs and management connections if you did enable a management profile)

 

second: if you added multiple interfaces to the same zone, or you're somehow bouncing connections off of the interface because you neglected to inform a host of a downstream router, these packets will be allowed to pass through. 

for the former I'd VERY MUCH prefer to see specific security policies apply security profiles (scanning) to the connections and the latter will cause problems anyway because the return packets from the destination behind the downstream router will be returned to the original host directly causing the firewall to have half-open sessions and eventually blocking the packets anyway (you need U-TURN NAT to fix this btw)

 

 

 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization


@reaper wrote:

by default there is indeed an intrazone allow all policy which will only allow session inside the same zone

 

there's 2 common uses for this policy (with the second one not being my favorite, but it's there as an FYI)

 

first, you will allow connections to the firewall interface, which won't do anything and get dropped anyway if a service is not attached to a socket (but it facilitates VPNs and management connections if you did enable a management profile)

 

second: if you added multiple interfaces to the same zone, or you're somehow bouncing connections off of the interface because you neglected to inform a host of a downstream router, these packets will be allowed to pass through. 

for the former I'd VERY MUCH prefer to see specific security policies apply security profiles (scanning) to the connections and the latter will cause problems anyway because the return packets from the destination behind the downstream router will be returned to the original host directly causing the firewall to have half-open sessions and eventually blocking the packets anyway (you need U-TURN NAT to fix this btw)

 

 

 


 

Thanks for the reply. If the external interface is only needed for VPN and Management Profile, are you saying, it's fine having untrust -> untrust allow,  or would you create more specific rules?

 

Sounds like you're saying since the firewall will drop the connection if a service isn't attached, it's not a problem to have this allow any application/server from untrust to untrust rule.

 

Just doesn't seem right to me, but I'm open to opinions

 

You would also allow all traffic to your servers visible from internet if you have some DNAT rules to inside (instead of DMZ). Let's say you make NAT rule for Exchange; if you NAT all services the rule you mentioned  will allow all traffic from internet to your server, smtp, https, rdp... Which is not something you want.

 

So make rules very specific, deny everything first then allow only what is needed.

 

 


@santonic wrote:

You would also allow all traffic to your servers visible from internet if you have some DNAT rules to inside (instead of DMZ). Let's say you make NAT rule for Exchange; if you NAT all services the rule you mentioned  will allow all traffic from internet to your server, smtp, https, rdp... Which is not something you want.

 

So make rules very specific, deny everything first then allow only what is needed.

 

 


no, your security policy zones are post-nat (while the destination IP is pre-nat) so to reach your servers you need to have a policy from untrust to dmz.

Untrust to untrust will not allow this

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

Somehow I was sure I read Untrust>Trust in his post. Sorry. Was before first morning coffee...


@ce1028 wrote:

@reaper wrote:

 

blablabla

 

Thanks for the reply. If the external interface is only needed for VPN and Management Profile, are you saying, it's fine having untrust -> untrust allow,  or would you create more specific rules?

 

Sounds like you're saying since the firewall will drop the connection if a service isn't attached, it's not a problem to have this allow any application/server from untrust to untrust rule.

 

Just doesn't seem right to me, but I'm open to opinions

 


I Would still create more specific rules if possible. These rules are in place for convenience so you can set up your environment and give your attention to the most pressing matters first, then once you have your operational configuration in place you can narrow down your rules to the most optimal security stance for your environment. https://www.paloaltonetworks.com/documentation/best-practices 

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

@santonic lol funny, I know the feeling

 

@reaper This is what I thought. I would delete that untrust - untrust rule, and create say a VPN Rule, select source zone untrust, destination untrust (+ ip address) with applications IKE, IPSec, etc.  You agree?

well their untrust untrust allow does not do anything in it's own as the default policy would already do what it does (allow intrazone traffic)

 

you could certainly rebuild that policy to only allow the applications you want, like ike and ipsec, and then set the default rule to drop instead of allow, or create a deny all rule for untrust at the end

Tom Piens
PANgurus - Strata specialist; config reviews, policy optimization

My guess would be they wanted a logging profile on the default rules and did not know how to override them...


@reaper wrote:

well their untrust untrust allow does not do anything in it's own as the default policy would already do what it does (allow intrazone traffic)

 

you could certainly rebuild that policy to only allow the applications you want, like ike and ipsec, and then set the default rule to drop instead of allow, or create a deny all rule for untrust at the end


 

The default rules don't do anything in this case because there is an explicit deny any rule above them.  The untrust -> untrust rule is above the deny all rule

  • 1 accepted solution
  • 10682 Views
  • 11 replies
  • 0 Likes
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 LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!