Best practices for allowing overlapping ports/protocols on different rules

[kamilazat]

Hi,

I've read that it's not best practice to have multiple service objects defined for the same port/protocol here. And it got me thinking.

What is the best practice in case we need to create rules with overlapping port ranges with the same protocol?

For example, let's assume that

•     I need to allow access between Network A - Network B on ports 10000 - 20000 on protocol X.
•     But at the same time, I need to block traffic between Network C - Network D on ports 15000 - 25000 on protocol X.
•     Additionally, a new requirement comes and I need to create a new rule that allows access between Network E - Network F on ports 12000 - 27000, again on protocol X.

The first thing that comes to my mind is to create different service objects for these different ranges and use them where needed. But if I understand it correctly, it's not the best practice and probably will give me "Services port conflict" warning when installing the policy.

How do we do this in this kinds of situations?

Cheers!

[emmap]

Create the service ranges as required for your rules, but under the Advanced options for those objects, make sure 'Match for Any' is not selected. That way you'll have no warnings on policy install.

[kamilazat]

Thank you!

What if I also have rules that have 'Any' in service column? How does unchecking 'Match for Any' affect those rules?

[emmap]

It doesn't affect them at all, it just means that the service ranges you create are not considered when matching services for traffic that hits the rules with 'Any' service in them. 

[kamilazat]

So if I, say, unclick the 'Match for Any' in FTP port 21, and allow TCP traffic over port 21 on a rule, the firewall will allow the traffic but won't treat is as FTP protocol anymore. Do I understand it correctly?

Then what would happen if I turned it off on all the services in a 5000 rule Policy Package? I mean, why is it needed then?

[Duane_Toler]

You can't "just" allow traffic on port 21 without a service object for port 21.  You can create a new TCP service object, give it port 21, do as EmmaP said, and don't assign the protocol type.  You can use this custom service in the rule which the firewall will treat with no further deep packet inspection.

The "match for Any" checkbox is a complex process:

1. For any rules whose Service column is "Any",

2. Find all service objects whose checkboxes are "match for Any",

3. If the port number in the packet matches that object's port number,

4. Apply the deep packet inspection protocol handler.

This means if you have a rule where Service column is "Any", and try something "clever" like "SSH over TCP port 80", the firewall will know this is not an HTTP protocol in the packet payload, so the packet will be blocked.  Similar will apply if you have Service column "http".

So "Any" does not strictly mean "Any".

[kamilazat]

Now I understand better, thank you.

And a similar principle goes for higher custom ports, am I correct?

[Duane_Toler]

Yes, but any port.   1-65535.  Firewall doesn't care about what a "privileged" vs. "non-privileged" port is; that's only meaningful on the host where the port is created.