Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted

When policy verification will validate also port numbers instead of service name?

Rules above are passing verification process without any issues, since verification process don't look on port defined in service but rather check only service name. This basically create shadowed rules in policy.

Should it be verification failure, when services are exact same ports on both rules?

Only difference between http/s and http/s-30mins is with custom advanced settings on service properties.

Labels (2)
7 Replies
Highlighted

Those are two different service beside port number , you can have rule like this for decide to not synchronize certain type of traffic between cluster member just cloning the default service and select do not synchronize between cluster member so I guess the verify mechanism is work as expected at least in this case .

0 Kudos
Highlighted

It's still same port. There will be no hit counts rule #2

Highlighted
Advisor

Could you detailed advanced settings difference between both of them ?

0 Kudos
Highlighted

Hi, the Security Management Server has it as warnings as you make the change. We plan to create a page for the "live" warnings since the "validations" pane only shows publish-blocking errors. Multiple services with the same port is not a security problem. You can use either of them in the same policy. However, we realize that some of our customers would like this as an error and we plan to add this configuration flexibility in our next releases.

0 Kudos
Highlighted

Tom, its not an issue that you can have multiple services with same destination port, but if it for verification process only care about only name of service, then it's allowing to create shadowed rules. Right now if i want to see shadowed rules i need to use tools like Tufin,  Firemon, Algosec.

0 Kudos
Highlighted

multiple services with same name are blocked with R80.10 Security Management.

Check Point fails policy installation for shadowed rules. In case objects are shadowed but belong to groups, Check Point does not fail policy installation, because we aren't sure that administrators are willing to break their groups apart for the purpose of narrowing down their rules - but we'd love to hear a different approach.

0 Kudos
Highlighted

Unique name is required for all network objects since r80.10, which is good, but this is about something else.

It's checking shadowing for network objects definitions, but not for services that's my point.