Custom Application - RegEx implications - what's preffered here?

[MarNeu]

Dear community,

in two recent TAC tickets we got advised to replace our standard custom applications with ones using regular expressions since that has lower performance impact on the gateway. Both refered to this sk165094

Unfortunatelly this pretty easy sounding task turned out to be really tricky. And I'm still unsure if regex is really the prefered more efficient way?! Does someone know?

There are several things to keep in mind when using regex:

1. Is the traffic getting HTTPS inspected (de- and encrypted)
2. Is the traffic unencrypted (e.g. HTTP for redirects)
3. If encrypted, what is the SNI of the used certificate (e.g. when a custom app is for a sub domain, but the certificate is a wildcard on the main domain)

Since all this information is offen hard to gather, it is pretty hard to define an appropriate regex (or multiple).

In my opinion Check Point should make it easier for admins here. The admin should only need to define the domain / subdomain / URL / ... and checkpoint should care about performance efficient handling of the different situation.

Of course a possiblity to let admins create there own regex would still be a nice to have for some cases.

I would really appreciate some feedback from other admins how they handle this topic.

Some examples:

For unencrypted / decrypted traffic we use: \/sub\.example\.com/

For encrypted traffic (this goes on SNI) we use: \.sub\.example\.com + ^sub\.example\.com

Before using regex we used for all cases: sub.example.com + *.sub.example.com

Thanks a lot for all your help and effort,

Best Markus

[Chris_Atkinson]

To clarify were you using the wildcards (*) with or without regex syntax enabled before?

For me this is the key point, when you move to regex avoid wildcards.

[MarNeu]

Sorry to not mention that. Before with the wildcards there was no regex syntax enabled. We checked the box when migrating the custom apps towards the new regex syntax.

[Tobias_Moritz]

I read that sk a long time ago and I understand it that way, that regex with wildcards are a bad idea, which makes sense from the parser performance point of view.

However, I thought that wildcards without regex are not so problematic and it is not worth migrating to regex (without wildcards).

But the OP says, TAC has advised them to do so. Your question, @Chris_Atkinson, sounds like avoiding wildcards is only important when ticking that regex check box.

So what is better from the performance perspective:

Wildcard without regex or regex without wildcard?

[Marcel_Gramalla]

I also think that there could be a more easy and understandable way to configure it but we actually do it like in the sk but we haven't done any migration and just started to use this last year. And I have to say that it works perfectly fine with and without HTTPS Inspection (thanks to SNI). We do it like this for nearly all domains:

• \/youtube\.com
• \.youtube\.com

It would be really cool if there was a synax checker build in to the SmartConsole so you can define the RegEx and just paste an URL and see if it would match or not. Our old proxy does this and it also has no problems with wildcards etc. The question is also what the real performance impact is and about how many definitions we are talking. 

Maybe Check Point says that it is only relevant when defining many thousands of domains etc. or only with many thousand connections per second. It probably is a classic "it depends" answer 🙂

[Stealth]

"It would be really cool if there was a synax checker build in to the SmartConsole so you can define the RegEx and just paste an URL and see if it would match or not. Our old proxy does this and it also has no problems with wildcards etc. The question is also what the real performance impact is and about how many definitions we are talking."

I like the idea of having a RegEx checker!