Custom Application Site url substring wildcard

[mcdonamw_ews]

I'm trying to follow guidance as outlined in the following article:  https://sc1.checkpoint.com/documents/R80/CP_R80_SmartDashboard_OLH/html_frameset.htm?topic=documents...

It states:  

• The URL list supports the use of wild cards, for example to define the sub domains and paths of a top level domain. (*.checkpoint.com/*)

However, when trying to implement this, it errors saying the URL cannot contain the following substring: /*  (see attached image)

What am I missing?

[_Val_ · Accepted solution]

Remove the star after "/"

[mcdonamw_ews]

Will that actually match everything after / then?  I need to be able to match  <anysubdomain>.domain.com/<any-URI-directory>/<pages>.html etc.

[PhoneBoy]

Yes, it should.
FYI your messages were being held for moderation which is why they weren’t showing up.
This is the case for posts from new users as a sort of anti-spam measure.

[mcdonamw_ews]

Gotcha, thank you!

Would be helpful to notify users of this moderation, or did I perhaps miss such a notification?

[_Val_]

@mcdonamw_ews we do review moderation queues several times a day. Notifying actual posting users is not part of the process, for some good reasons.

Thanks for your understanding. 

[Bob_Zimmerman]

You may not need the leading wildcard either. In the past, I was told to block a short domain and it ended up blocking occurrences of that domain in the path as well. Think blocking the .ar TLD, and the application/site object also matching some.site.here/now/a/path/left.arrow.png

[mcdonamw_ews]

Thanks for the input.  This seems unnecessarily complex.  Does Checkpoint support monitor these forums at all?

[PhoneBoy]

R&D does.
Custom Application/Sites are meant to match URLs, not just hostnames, which are naturally a little more complicated.

[mcdonamw_ews]

---

@PhoneBoy wrote:

R&D does.
Custom Application/Sites are meant to match URLs, not just hostnames, which are naturally a little more complicated.

---

I figured.  Unfortunately the situation I face is that I have protected networks that are not allowed external internet traffic except for applications that need to reach their hosted SaaS provider (since everything is going cloud).  Ideally I'd want to do this via the security policy and use of hosts/networks, but it's impossible when some of these providers are using backend providers like AWS and suggest we open ourselves up to entire /8 - /16 networks because they cannot give us specific dedicated hosts or they simply ask us to whitelist their domains. 

As such I've had to resort to allowing outbound to the internet in Security policy and try to further limit it via Application policy, which leads me to where I'm at now.

I simply want to allow access to  domain1.com, domain2,com, etc.  I'm just running into issues doing this because I don't want to open it up to JUST https://domain1.com (and have something like https://app.domain1.com/somedir/somepage.html being blocked because the interface isn't clear as to how to properly enter criteria to match what I need.  The guide suggests use of wildcards, but the UI won't allow me to type them in as suggested, hence the problem that lead me here.

[PhoneBoy]

Regex can be a bit more precise than wildcards (though naturally you can also get into more trouble with them).
That said, *.example.com/ should do what you're after.
Note for this to work without HTTPS Inspection enabled for HTTPS URLs, you will need to be on a version that support SNI.
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut... 

[_Val_]

@mcdonamw_ews If you need TAC assistance, please open a ticket. The community is not a support channel.

[mcdonamw_ews]

---

@_Val_ wrote:

@mcdonamw_ews If you need TAC assistance, please open a ticket. The community is not a support channel.

---

Not looking for support.  Was just asking if they review the posts users create to better their product.  Thanks though.

[_Val_]

@mcdonamw_ews that was already mentioned by @PhoneBoy 

R&D is looking very closely to the community posts. And on our end, whenever we see something serious, we make sure the info is viewed and addressed internally.

[Bob_Zimmerman]

I don't know about unnecessarily complex. It does let you do some pretty powerful things, like defining exactly what calls one application should be able to make to another.

It would definitely be nice to have a type of object which only matches against some normalized form of the domain. Might be a good RFE. The normalization is important, as domain names are case-insensitive. If a case-sensitive match is used, then and object for mail.google would not match mAiL.gOoGlE, even thought the alternating-case version would work.

What's even more fun about that alternating-case thing: CNAME redirection typically preserves the exact input form for the domain components which don't change. When I look up that name, I get a CNAME to googlemail.l.gOoGlE.

[mcdonamw_ews]

---

@Bob_Zimmerman wrote:

I don't know about unnecessarily complex. It does let you do some pretty powerful things, like defining exactly what calls one application should be able to make to another.

---

Perhaps complex was the wrong word.  Non-intuitive is probably a better word?

People know what wildcards mean and know what to expect when using them.  To suggest not using them is very counter-intuitive as that does in no way indicate what exactly you're allowing or disallowing.   For example https://domain.com vs https://www.domain.com or https://www.domain.com/subdir/badpage.html.

Worse the manual/guide (as noted in my original post) clearly suggests the use of the wildcards.  Why would they suggest that but it not actually allow us to type them?  That's very confusing to end users.