Untrust to Untrust - Allow

[ce1028]

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?

[santonic]

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

[reaper]

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)

[ce1028]

---

@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

[santonic]

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.

[reaper]

---

@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

[santonic]

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

[reaper]

---

@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 

[ce1028]

@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?

[reaper · Accepted solution]

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

[JoeAndreini]

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

[ce1028]

---

@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