Is there a better way to block non-default app ports?

[Gareth.Doyle]

After parsing some logging I've discovered some trends in users utilizing non-standard ports for some App IDs and I want to prevent that. The first thing that comes to mind if to create a policy only allowing the app-default port, but the issue is currently this traffic is hitting a more general permit rule at the bottom of the policy stack. We are under going a longer grooming process in which we hope to have this cleaned up, but I want to prevent this non-application-default port access before then.

My next thought was to create a policy that allows app-default connectivity and list all of those applications in that policy, then a deny policy immediately below that for "any" service with all of the same applications.

Does this seem to best route to anyone or does anyone have any thoughts on a cleaner way to accomplish this?

I wish there was a "negate" option in the service so I could create a deny for any non-app-default and accomplish this in one policy rather than two, but as far as I know that is not an option.

Thanks!

[BPry]

@Gareth.Doyle,

Cleaning up the rulebase is really the answer to this sort of problem so that you aren't using broad allow entries for anything. Glad to hear that you at least have support to start cleaning this up, but it takes a lot longer to correct something like this than anyone would like. 

Your second option of creating an entry to allow these applications via a "allow" entry with an application-default service and immediately following it up with a deny with the service set to any would work perfectly fine. The only thing I would really question with that is why the deny statement is even needed? Could you cleanup the broad entry it's currently hitting so that it isn't matching this traffic and allow it to pass to the interzone-default entry, or is this broad entry you're currently hitting more of an "any-any" entry? 

[Gareth.Doyle]

Hey, @BPry , thanks for responding. So this traffic is going from a trusted zone to another trusted zone. When we migrated from one firewall to the PA we didn't want to inhibit this traffic (some is user support, some is server support, other is server to server service communications, etc...) so we added what is essentially a "trust to trust any" policy.

We are now in the process of refining things and bringing them more into line with the capabilities of a NGFW (e.g. app ID, decryption inspection) and also cleaning up overly broad policies such as the "trust to trust any" policy. This is part of the process of removing that policy, so eventually this deny policy I plan on creating can be removed, but in the interim I would like to block the off beat traffic.

I've learned my "do it all at once" lessons in the past and like to do the step by step approach these days. 

[BPry · Accepted solution]

@Gareth.Doyle,

Ahh okay. That changes things a bit since you aren't dealing with untrust traffic or anything like that.

The way that I've dealt with this in the past is to start identifying services that actually need to communicate with system owners to build out security rulebase entries for them as specific as I possibly can. The "trust to trust any" entry continues to exist as we work through identifying all of the traffic that should be allowed, any denying anything that is identified that shouldn't be allowed (think normal default Windows traffic like Windows Update Delivery Optimization). 

Once you have traffic stop hitting the catch-all rule, there's two different ways that you can deal with it depending on environment. The "best" way would be to drop unidentified traffic on the catch-all rule and have it log. Depending on the size of the environment, you can setup a log-setting profile that could alert the firewall/NOC team of the traffic so you can see if a rule needs to be built out or not. The second way would be to keep the catch-all rule as allow and configure the same log-setting profile so that you're being alerted when it gets hit. 

This process is definitely a crawl before you walk and walk before you run type of situation, and it can take quite a long time to get everything into a good spot. I'm always hesitant in these type of situations when your dealing with internal "trusted" traffic to start denying it before speaking to system owners about it. The risk that you run is that you could have a critical business task get disrupted, or you have a lot of system/process owners complaining that you're breaking things. 

The benefit of going through the logs for this traffic and identifying it to tie everything back to a system owner and verifying the traffic is that you shouldn't disrupt anything, and even if you do you can point to the fact that your actively working to avoid any disruptions. Simply denying all applications on non-standard ports doesn't really give you that option, and you absolutely will end up breaking something.