Service Object - Match for Any

[Dave_Taylor1]

I'm working on Firewall standards for our security team and one of the items includes creating new services.

I know there are issues creating new objects and leaving the default "Match for any" selected, but I'm not able to find specific details for this in any of Check Point documentation.

What is Check Point's recommendation regarding this?

[Nick_Doropoulos]

Hey Dave,

Please find below Check Point's documentation with regards to the feature in question:

Match for Any: Indicates whether this service is used when 'Any' is set as the rule's service and there are several service objects with the same source port and protocol.
When there is a rule whose Service cell contains Any, and a connections protocol and source port match more than one service object, then the service object with the selected 'Match for Any' option will be used and its properties will be taken for handling this connection.

When installing a policy that contains services that have source ports (specified in the Advanced window) that require the Match for 'Any' option to be selected, a warning appears. The policy will be installed with a warning (for each such service), since Match for 'Any' is not supported for services that contain source port specification.

I hope this helps.

[Dave_Taylor1]

So if I understand this correctly, what that says, is if you create a Match for Any service, it should not be used in a rule as a service......Right?

[Nick_Doropoulos]

To clarify, the "Match for Any" setting really comes into play when there are several service objects that use the same source port and protocol. If this scenario applies, on the interesting firewall rule you could do either of the following under the Services column:

- Leave it to "any" and enable the "Match for Any" checkbox of the service object you want to match the traffic so to speak.

- Specify the exact service objects you want to match.

Again, I believe this setting is more relevant when multiple service objects use the same source port and protocol so it just gives you an extra layer of granularity.

Let us know if you have any more questions.

[Norbert_Bohusch]

To clarify things:

The "match for any" checkbox is only relevant if the service column of the rule is set any. Then the specific settings for the service are used for setting timeouts, cluster-sync, protocol inspection, etc. for traffic matching this rule and the protocol/port of this service.

If a specific service is used in a rule, then the specific settings of this service apply and it doesn't matter if "match for any" is set!

[Benedikt_Weissl]

Think of the "any"-Service as a collection of all service definitions. A service object has far more attributes than just destination port.  Its possible to have 2 service objects with the same destination port but otherwise different settings like virtual session timeout or protocol handler.

Lets assume you configured a service called "service a" with tcp destination port 8080 and a session timeout of 30 seconds and "service b" with tcp destination port 8080 and a session timeout of 60 seconds. Both have have the "match for any" attribute set. Then you create a firewall rule like this:

Source: Internal -> Service: Any -> Destination: Extern.

Now you access port 8080 on an external server from your internal network. 

What would be the virtual session timeout for this connection? 30 seconds or 60 seconds? Should the log show "service a" or "service b"?

Best practice in my opinion would be to avoid creating overlapping service definitions. If you have to define 2 overlapping service objects, unset "match for any" for one of them.

[mdjmcnally]

The big problem that you have (as is mentioned but not too clearly in the information) is where you have multiple services that have an overlap of ports.

ie you define a service port range of 6000-7000 and have a service defined for say 6500, 6509, If they all have the Match for Any checked then when you install the policy then completes with warnings about multiple services matching a port.

If you don't clear that up then what happens is people get used to seeing the warning and so don't look.    Have seen people miss warnings about Certificate Expiry and the like because of this.

[Dave_Taylor1]

This is also been my experience. We have many service ranges, and I see that error during a policy install. It also poses an issue searching within the logs for a specific service that may fall in that range.
Thank you

[PhoneBoy · Accepted solution]

Generally "Match for Any" is only an issue when you have two or more services defined using the same TCP/UDP port.
If that's the case, the definitions for the service marked "Match for Any" for a given TCP/UDP port will apply when a particular connection matches a rule with service Any.
This can include service-specific timeouts as well as the application of the protocol handler that's associated.

At the moment, when you create a new service, we leave this checked by default.
We are considering changing this behavior in R80.40.

[Dave_Taylor1]

Thanks, I appreciate your help.

[Mike_Jensen]

Hello,

For clarification; if I have a service object for a port range and do not have the match for any set, and then a cleanup rule in my  policy to drop "any" service to network 10.x.x.x, does the port range defined in my service object not apply and those ports can still access network 10.x.x.x ?

[Bob_Zimmerman]

"Any" in the service column of a rule is shorthand for IP protocols 0-255, TCP ports 0-65535, UDP ports 0-65535.

The "Match for Any" checkbox in service objects only controls which service object's settings are used for connections which hit a rule using "Any" in its service column. These settings include timeouts, protocol inspection, and whether to set up a virtual connection for UDP replies. For example, domain-udp is configured to set up a virtual connection to accept replies, and it is set to match for any. If you have a rule which allows 10/8 to reach 4.2.2.2 via Any, and 10.20.30.40 sends a DNS request to 4.2.2.2, the reply will be accepted. If you uncheck "Match for Any" in the domain-udp service object and push policy, the DNS reply will no longer be accepted.

[Mike_Jensen]

What about the "Accept Replies" check box?  I wanted to assume having that checked would allow the reply to be accepted.

[Bob_Zimmerman]

On a rule which uses that service, sure.

On a rule which uses "Any" in the service column, you need to have a service object for the port in question, it needs to be set to accept replies, and it needs to be set to "Match for Any". This is literally what the "Match for Any" box is for.

Also, minor correction to what I said earlier. There is a small range of ports (TCP 6000-6063, I think) which is not included when you use "Any" in the service column of a rule. The range was used for clear X11 connections in the past, and to allow ports within it, you need an explicit rule.

[Mike_Jensen]

That makes more sense now the way you explain it.  Thank you very much.

Basically in summary for the firewall to be "statefull" and accept the reply traffic, if a rule using the service "any" is used there needs to be a service object set to accept replies if I expect to get the return traffic?