topic Re: The dreaded any in General Topics

The dreaded any

jdprovine — Tue, 07 Nov 2017 17:24:39 GMT

I got a health check report and according to it I have a least one any in every single rule I have on my firewall. I was just curious if anyone has been able to have at least one or more rules with no any's at all.

Re: The dreaded any

Kaje — Tue, 07 Nov 2017 20:20:56 GMT

Yup, I have a few (excluding HIP profile) you just specify your zone, and source address, or source networks, Destination zone and networks, you can select multiple of any of these. Specify users (I do groups in AD)Then specify the applications or application filters, and there you go, a rule with no "ANYs".

Re: The dreaded any

Mick_Ball — Tue, 07 Nov 2017 20:55:45 GMT

Hmmmm... interesting question and even more interesting first response, not sure why you would specify a source ip address and a source zone, or a destination ip and destination zone, unless i am missing something obvious, but of course if you can then why not?

on call at the mo and a bit bored so let me offer a curve ball, does anybody have a rule that consists of all “Any”. I must admit that i do.

Re: The dreaded any

jdprovine — Tue, 07 Nov 2017 20:58:32 GMT

@Mick_Ball

Its a tough one and I begin to wonder what your rule number would have to be to eliminate all your any's. I was just surprised that we didn't even have one rule without any's

Re: The dreaded any

Kaje — Tue, 07 Nov 2017 21:05:53 GMT

The reason to do both Zone and IP, is firewall with many zones, and possibly multiple virtual routers!

I personally dont have a problem with an ANY in the right spot, some times you really dont need to be that specific. some rules, you need to get VERY specific!

Re: The dreaded any

jdprovine — Tue, 07 Nov 2017 21:34:24 GMT

I believe that best practices indicate having as specific a rule as possible for higher security, but obviously that isn't always possible

Re: The dreaded any

Mick_Ball — Tue, 07 Nov 2017 21:36:51 GMT

@Kaje.. noted, and of course you are correct... my fault for assuming all networks were like ours.. private, external and dmz. With one vrouter.

i agree with using “any” where possible as always assumed that any implies “do nothing” thus less load on processing and easier diagnostics.

shame you are not using HIP, you could have hit the jackpot...

Re: The dreaded any

Mick_Ball — Tue, 07 Nov 2017 21:53:51 GMT

@jdprovine... strange you should say that.... we also have policies tied down to AD users and groups that can only traverse via the trusted interface, purely because of our setup, so... its wierd that we still add the trusted zone (but not ip subnets) to our policies, whereas we could just rely on AD. Must be a habit/confidence thing...

Re: The dreaded any

Mick_Ball — Wed, 08 Nov 2017 08:51:41 GMT

and yes our ANY ANY ANY ANY ANY ANY ANY rule is the last. it's set to deny for diagnostics. I find this quite helpful as our other policies are logging session end only.

we do not log the above rule to paranormal for obvious reasons...

Re: The dreaded any

bmorris1 — Wed, 08 Nov 2017 11:50:45 GMT

@Mick_Ball you can override the default inter-zone deny rule (panos 6.1 and above) and set the log action to get the information from a 'deny all' rule. Currently your rule would deny intra-zone traffic as well.

Re: The dreaded any

Mick_Ball — Wed, 08 Nov 2017 12:16:21 GMT

noted @bmorris1. thankyou.

we don't have inter-zone traffic so seems OK for me, that may be simply because i don't fully understand inter-zoney stuff....

google.... incoming..

Re: The dreaded any

BPry — Wed, 08 Nov 2017 21:58:27 GMT

@jdprovine,

I actually have quite a few rules that don't mention a single 'any' statement (including HIP this goes down to a few), to the point where if I use an 'any' anywhere in a security policy I spend more time creating justification for it then creating it. Zone I always specify, address is always specified even if it's the entire range in that zone, user is always at least known-user, destiantion is almost always filled, applications specified, services specified or application-default.

There are obviously times where you can't get away without an 'any' statement. For example general browsing rules are almost always going to specify an 'untrust' destiantion zone but include an 'any' as the destiantion. Source-user is really something that should mostly be populated if you expect to see user ids across your network; why allow an unknown user access anything? Part of it to is how many rules you actually have; on average I run between 250-300 rules, I've worked on firewalls that had over a thousand. Once you get that specific with your equipment, it would kind of be really unusual to see an 'any' statement in some of those policies.

Re: The dreaded any

BPry — Wed, 08 Nov 2017 22:01:02 GMT

@Mick_Ball,

It's been a while since I've seen a medium sized company have a 'true' DMZ. I've seen more and more traffic go through a load-balancer that's in the DMZ, but then accesses internal servers for content. Makes me want to scream when people don't understand what the DMZ is supposed to be used for.

Re: The dreaded any

jdprovine — Thu, 09 Nov 2017 14:08:10 GMT

We have 377 rules right now and I have always been told that it is a more secure rule if you can minimize or eliminate the any's, so when the health check we had run by PA showed everyone of our rules had at least one any in it, that caught me off guard. So I am always looking for way to eliminate any's and make the rules more specific

Re: The dreaded any

Remo — Sun, 26 Nov 2017 18:09:26 GMT

@BPry You probably have the ruleset(s) I'd like to have. But don't forget to specify also the "url category" column to get a rule without "any" 😉 😛

But unfortunately it heavily depends on the customer ... user-id? "Yes please, but as a nice to have not a must" ... app-id? "Just go with port 80 and 443, because we don't wan't to upset our employees" ... Anyway, I think it definately isn't that critical if you have any in the rules at least for general client access rules (active directory, exchange, fileservices, ... , internet) (->with strict source routing enabled in ZP profile, I don't see a reason for specifying addresses when you want to allow this whole zone to access some ressources)