How to create a custom application with custom services?

[Raj_Khatri]

Does anyone know how to create a custom application with custom services?  It seems you can modify an existing application and add custom ports, but you cannot create a custom application with custom ports.

[Tomer_Sole]

Hi,

Are you referring to custom URL's or custom application signatures?

[Raj_Khatri]

Custom application services.  Here is a screenshot when you create a new application and cannot define any services.  The other screenshot shows you where you can modify the services.

[Tomer_Sole · Accepted solution]

Hi,

This is a limitation of R80 that will be added in the next releases.

As a workaround for now, you can change the services from "any" in the "services" column in the layer. You will need to do it in every location that uses that application.

[Julia_Farrugia]

Hi,

Was this fixed?

[Tomer_Sole]

Hi, the same behavior was kept in R80.10. We plan to change that, but at the moment cannot commit to a specific release.

[Aaron_Hajba-War]

Tomer - is there any update on release of this?

[PhoneBoy]

For custom applications/URLs, the ports defined for "Web Browsing" will be used.

You configure those here:

If you only want to allow a specific set of ports for a specific application, then you might want to use the Application Control Signature Tool to create an appropriate signature: Signature Tool for custom Application Control and URL Filtering applications 

Doesn't appear (at least in the current public EA) this will change in R80.20.

[Aaron_Hajba-War]

Thanks Dameon,

I have taken a look at the tool and it doesn't appear that i can do a custom URL with custom port - Only seems to be to a specific IP address.

We are only wanting to allow access to a particular URL on port 22.

[Aaron_Hajba-War]

Hi Tomer,

Do you know if the new R80.20 Manager enables this feature?

[PhoneBoy]

As far as I know it does not.

But it seems like you could accomplish this with the regular rulebase too.

Are the gateways in question R80.10?

[Aaron_Hajba-War]

Yes they are 

[PhoneBoy]

Then you should be able to do something like the following:

The basic logic is:

• Handle all "Port 22" traffic in an inline layer.
• In that layer, match "allowed SSH traffic" plus access to the specific URL you want to allow over port 22
• In a rule after the inline layer, ensure you explicitly drop traffic to the specific URL.

Granted, this is not quite as easy as if custom applications also allowed you to specify ports, but this will allow you to achieve the desired result today. 

[Hugo_vd_Kooij]

Right,This is why inline layers are so much fun. How could we ever live without them?

[Djelo_Arnautali]

Unfortunately this does not work for ftp custom rule (Gaia R80.10). The customer want to permit only ftp from a specific server to ftp.hp.com. 

I have created the rule that permits ftp from that server to any and the action is FTP inline rule where i have configured the first rule to permit custom application (ftp.hp.com) and the second rule is a clean up rule. In the log the traffic only match the clean up rule and the connection does not work. In your case in the log it would show drop packets matching rule 1.3.

[PhoneBoy]

How are you defining the custom application for ftp.hp.com?

I suspect those don't work for FTP.

What you probably want to do instead is use an FQDN domain object and have a simple rule that permits ftp from the desired server to ftp.hp.com (which I assume may have multiple IPs, otherwise use a simple host object).

[Djelo_Arnautali]

I also think that the custom application wont work for FTP because when you define New Application/Site in the section Match by there is by default services for web browsing which are defined in the App & URL filtering settings and by default there is no ftp protocol there. I have tried just for test to add there also ftp protocol and define New Application/Site with URL list: ftp.hp.com and still this does not work. I think this is coded to be used as a "logical and" meaning that both the protocol and url configured has to match but for ftp is not working. I am not sure it will work for ssh either.

[Carlos_Machado1]

Hi, Dameon.

How does this contrast to the first reply on this topic? Custom Application by destination address / port combination? 

"In R77.30 App Control this can be defined very easily:

- Application & URL Filtering > Applications/Sites > New

- type name for App (mySpecialSite) and click Next

- type IP (172.27.39.198:8080), click Add and click Next

- select Additional Categories and click Next

- click Finish

- use App in policy"

I mean, I know the situation worsens with apps, but could I actually create a custom site object and just specify the URL with the ":port" attached to it? It doesn't seem to be working for me so far when using non-web browsing ports, like 9001.

I'm using R80.10.

[PhoneBoy]

In R77.30 and earlier, unless you've explicitly set the Service port, the allowed port is "Any" which allows this trick to work.

[Arnon_Azmon]

Hi,

I know this is an old post but the solution by PhoneBoy seems like exactly what I need, unfortunately it's not working 😞

I need to allow certain users RDP access to a computer on Azure cloud using DNS name.

I've hit the same issue with the custom application only matching by Web Browsing, so I've tried the workaround using inline layers.

However, in rule 1.1 (if reffering to the screenshot by PhoneBoy) the SpecialURL object still matches by Web Browsing, thus the FW ignores this rule and drops the traffic on rule 1.3.

Am I missing something?

Thanks,

Jonathan

[PhoneBoy]

You can use an FQDN Domain object for this versus a custom application/site, which only supports HTTP/HTTPS traffic (not RDP).

[Arnon_Azmon]

This was my first thought actually, before turning to App Control solution.

But everywhere I read I see warnings about using FQDN Domain object, even by Checkpoint themselves, saying they can create performance issues, should always be put at the end of the rulebase and don't actually always work... 

[PhoneBoy]

Most of the performance issues with Domain Objects were before R80.x.

[_Val_]

Well, to be technically correct, FQDN objects are supported with R80.x and do not cause performance issues. Legacy domain objects still have those, even with the latest versions.