topic Re: Untrust to Untrust - Allow in General Topics

Untrust to Untrust - Allow

ce1028 — Sun, 26 Aug 2018 19:00:30 GMT

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?

Re: Untrust to Untrust - Allow

santonic — Mon, 27 Aug 2018 05:56:20 GMT

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

Re: Untrust to Untrust - Allow

reaper — Mon, 27 Aug 2018 06:38:46 GMT

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)

Re: Untrust to Untrust - Allow

ce1028 — Mon, 27 Aug 2018 15:49:25 GMT

@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

Re: Untrust to Untrust - Allow

santonic — Tue, 28 Aug 2018 05:54:36 GMT

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.

Re: Untrust to Untrust - Allow

reaper — Tue, 28 Aug 2018 08:55:29 GMT

@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

Re: Untrust to Untrust - Allow

santonic — Tue, 28 Aug 2018 08:58:12 GMT

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

Re: Untrust to Untrust - Allow

reaper — Tue, 28 Aug 2018 09:20:03 GMT

@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

Re: Untrust to Untrust - Allow

ce1028 — Tue, 28 Aug 2018 20:51:35 GMT

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

Re: Untrust to Untrust - Allow

reaper — Wed, 29 Aug 2018 06:45:57 GMT

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

Re: Untrust to Untrust - Allow

JoeAndreini — Wed, 29 Aug 2018 11:21:34 GMT

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

Re: Untrust to Untrust - Allow

ce1028 — Fri, 31 Aug 2018 22:47:38 GMT

@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