any guide available for checkpoint regexp?

[Albin_Petersson]

helloes.

I've looked into creating some regexp rules, and they worked fine on R80.30 but not on R80.10. After some troubleshooting we gave up and have to do a different kind of syntax. But in the process i found sk165094 where a regexp is described, that at least i would say isn't a valid syntax. I'm not an expert on regexp though, so maybe it's a valid syntax?

are there any manual or documentation on "special" syntaxes that checkpoint has, or regexp in checkpoint in general?
That works on all R80 gateways independent of version?

[PhoneBoy]

It's fairly standard regexp and should be the same across versions.
The main difference between R80.10 and R80.30 is the lack of SNI support.

[Albin_Petersson]

well.. why does "\/" mean the same thing as ".*\." then? Or does it mean ".+\,"?
Is there anything internally that makes "\/" perform better?

I'm mostly confused. 😶

[PhoneBoy]

Regular expressions are a double-edged sword: they are very powerful but can come with a significant performance impact if they are made too broad.
The more precise your regex is, the better.

I suspect your definition of “perform better” is “match what I want it to match.”
Precise examples would be helpful.

Note that any differences may also be related to bugs in the relevant release versus differences in regexp syntax.

[G_W_Albrecht]

RegEx has nothing to do with CheckPoint and is the same everwhere it is used. My best loved RegEx sites are these:

Online regex tester and debugger: PHP, PCRE, Python, Golang and JavaScript

RegExr: Learn, Build, & Test RegEx

[Bob_Zimmerman]

Part of the problem there is I haven't yet seen documentation saying which regular expression syntax Check Point uses. Basic? POSIX Extended? Linux Extended? PCRE? Java? This affects which characters are actually metacharacters (and therefore need to be escaped) and which character classes are available.

[PhoneBoy]

I know the answer to that from past internal discussions: PCRE.
More specifically, PCRE-DFA mode.
Some suggested sites for regex creation:

• https://regex101.com/
• https://www.regextester.com/ - Use PCRE option
• https://regexr.com/ - Use PCRE option

[Bob_Zimmerman]

I have been requesting information about Check Point's regular expression engine for a few years.

The match is definitely case-sensitive. There was an option to make it case-insensitive back in the R77 family, but it seems to have been removed in R80 and up. Plan for lots of [cC][hH][aA][rR][aA][cC][tT][eE][rR] [aA][lL][tT][eE][rR][nN][aA][tT][iI][oO][nN].

While I know it seems to construct an entire URL including scheme and path, I don't yet know if there is any normalization performed when constructing the URL. For example, is the name always lowercase? No idea. Domain names are case-insensitive, but paths are case-sensitive, so this kind of implementation detail determines how we can write expressions.

The match is definitely run against the whole URL including path, as when a coworker tried to use "\.[aA][rR]" to block access to Argentinian domains, it caught files such as "right.arrow.png" on otherwise allowed sites.