The dreaded any

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

The dreaded any

L4 Transporter

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. 


L2 Linker

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". 



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. 



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

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!

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

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

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

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...

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



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..

Cyber Elite
Cyber Elite


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. 


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. 

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

L7 Applicator

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



  • 14 replies
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!