Duplicate Services – Which one gets used?

I was playing with the Match_Any on duplicate services just to see what gets hit when. I was debugging a H323 problem.

So when I created a second Port 80 HTTP with NO Inspect handler and left it checked as Match Any (I did have it checked)matchanychecked

In this rulebase

rule base w two port 80

I got this error

verify error

But when I unchecked it (like you see above) I was able to install and browse with it.

SO what service did it use for browsing? The standard HTTP or the Generic?

What happens if I telnet to port 80 and type in junk??

10-25-2013 5-37-58 PM

They both use the Standard HTTP. Interesting Huh??

OK, get ready to see something even cooler!

Swap the services in the rulebase

swaporder

What do you think will happen????

swapresults

Pretty neat?? The INSPECT handlers do not get invoked even though the header was a HTTP GET command.

Who Cares?So the service logic is pretty dumb and if you have a couple conflicting services in some

huge buried service groups, then you better know which one gets hit first.

So lets look at the ANY rule.

I fix up the rulebase and make both services “Match Any”

fulebase

Look what happens. This is good.

confg

Try it anyways and OK the standard one gets hit.

conflic

So I take OFF the “Match Any” from the Generic HTTP. It all installs fine and see what we get.

resultsOK

Which seems OK. It favors the INSPECT script. Not sure what the INSPECT is doing if it allows Telnet of garbage, but that’s the deal McNeal – beggars can’t be choosers.

Summary:

1) If there are conflicting ports in a rule, the first one found will be used. So if you have huge groups of services make sure there are not any conflicts OR make sure you know which one will be hit first.

2) The “Match For Any” flag is used to put a services into the “Any” group. Note that the bigger this “Any” group is, the slower the rulebase will be so use it judiciously.  If there are conflicts in the “Any” group, then the INSPECT enabled service seems to be favored (but I can’t verify that).

3) Services like H323 are weird because (IMHO) CP’s implementation is flawed (see my previous blog). So if you create new generic services make sure you call them out explicitly in the rule and don’t rely upon the “Any” rule to catch packets that drop from your rule because you will hit the INSPECT H323 rule and not the Generic rule.

Advertisements
Post a comment or leave a trackback: Trackback URL.

Comments

  • Arska  On October 26, 2013 at 12:32 pm

    Are you sure, that Smartview tracker will get the real service used? Or does it just quess service name based on port? At least some years ago I investigated the same thing (R71 or something like that) and although rule that matched had service http, Tracker showed one of my custom service for port 80.

  • Dreezman  On October 26, 2013 at 6:47 pm

    Very good point! I’m not sure. Hmmmmmmm. Trying to think how to test that….But did you notice that when I switched http and generic, that it picked the first one….I wonder if service uses a UID….Hmmmmmm.

  • wmlubas  On October 27, 2013 at 6:18 am

    If I understand scenario correctly (“any” rule, and two or more services for the same port/protocol and match for any enabled) – gateway will match the service which is first in objects_5_0.C file. I’ve seen problems after migration to new CMA, where services where created in different order – gateway managed by old CMA matched plain tcp/port service, while in new configuration it matched service with application layer protocol inspection. That being said about gateway, I am not sure if smartview tracker is using the same logic.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

blog.lachmann.org

Michael Endrizzi's - St. Paul MN - CheckPoint blog on topics related to Check Point products and security in general.

%d bloggers like this: