custom url category with non http and https port.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

custom url category with non http and https port.

L2 Linker

HI,

 

I Have created custom URL category e.g  category name (*.xyz.com) Now I want to create inbound rule like below.

 

Source zone :- Internet 

Destination Zone :- LAN

Destination IP :- Any

Port :- 389 , 4172

URL Categary :- 'Custome category'

Security Profile : Any

 

My doubt is will this work on port 389 and 4172 port or this will work only on http and https port

 

Thanks

Dhananjay Bhakte

 

 

1 accepted solution

Accepted Solutions

Hi @DhananjayBhakte 

Custom URL categories only work for http and TLS traffic - not only for apps web-browsing and ssl as there are quite a few more that are based on http/tls traffic - but at least for ssh you cannot use a custom URL category. 

View solution in original post

11 REPLIES 11

L2 Linker

Hey,

 

could you please clarify what you are trying to achieve here? The application and the service are independend of each other. You can easily create a rule allowing SSL and Web-Browsing on port 389 and 4172.

Kind regards,
René
// If you like my answer force commit it.

HI Rene,

 

I have requirement from customer to open port 389 and 4172 for eg *.xyz domain.

So I created custom category *.xyz.com and have to create rule by calling this category into rule and will allow only 389 and 4172 ports.

As far my understanding url category work only for ssl and web-browsing traffic, so just wanted to know if I keep url category in rule for port port 389 and 4172 will that rule work?

 

Thanks

Dhananjay

Hi,

 

ok now I got you. So you are correct URL filtering is working with http/https only. Futhermore it is kind of uncommon to have URL filtering active in inwards direction. So I saw the request for port 389 which is basically LDAP, dont know for 4172. However please make yourself familiar with the conecpt of an "application firewall" - we do not open ports anymore. But in term of customers request you are right, this is not going to work.

Kind regards,
René
// If you like my answer force commit it.

Hi @DhananjayBhakte ,

 

It sounds like you need FQDN not URL. 

You can use FQDN object as source or destination address in the policy. Firewall will query the DNS server and use this fqdn to resolve it to IP address. The received IP will be cached for configured amount of time (probably 30min was the default, but not sure). 

Given the port from your description it sound be more reasonable to use FQDN instead of URL filtering. 

 

To be more precise URL custom category  will work with web-based application. If you think for a bit it is logical - firewall needs to know which part of the traffic is the URL, so it doesn't matter what port you are using

HI Alexzandar,

 

Traffic is not URL traffic and its application is not applicable. 

For known fqdn e.g abc.xyz.com it is possible to write rule however fqdn is not fixed, customer says fqdn will change every time but domain (xyz.com) would be fixed, So my query is Can I allow wildcast *.xyz.com instead of single fqdn in security policy using custom url category for custom ports.?

 

Thanks

Dhananjay Bhakte

 

 


@DhananjayBhakte wrote:

HI tellthebell

 

Traffic is not URL traffic and its application is not applicable. 

For known fqdn e.g abc.xyz.com it is possible to write rule however fqdn is not fixed, customer says fqdn will change every time but domain (xyz.com) would be fixed, So my query is Can I allow wildcast *.xyz.com instead of single fqdn in security policy using custom url category for custom ports.?

 

Thanks

Dhananjay Bhakte


You can use FQDN object as source or destination address in the policy. Firewall will query the DNS server and use this fqdn to resolve it to IP address. The received IP will be cached for configured amount of time (probably 30min was the default, but not sure). 

Given the port from your description it sound be more reasonable to use FQDN instead of URL filtering. 

HI Couvertjy,

 

Now I allow policy as below,

Source Zone :- Internet

Source IP address:-  x.x.x.x

Destination Zone :- Lan

Destination IP address:- Any

Custom URL Categary :- *.xyz.com

Port :389 and 8759

Action : Allow

 

It is working, but my question is still there as *.xyz.com is hosted on internet so how can firewall allowing  xyz.com fqdn to access ports on Lan zone through Custom URL category?. So here URL category is acting as source IP . So is it possible that custom url category can act as source or destination IP.

 

Thanks

Dhananjay Bhakte

let me correct my below comment

 

Source IP also any 

 

Source Zone :- Internet

Source IP address:-  any

Destination Zone :- Lan

Destination IP address:- Any

Custom URL Categary :- *.xyz.com

Port :389 and 8759

Action : Allow

L2 Linker

HI,

 

In addition to above query, I got new requirement from customer as below

 

Source Zone : trust

Source user :- abc

Destination Zone :- Untrust(internet)

Destination :-  *.ncra.tifr.res.in

Port : 22

Application: SSH

 

So to achieve above requirement  , I have created custom url category as *.ncra.tifr.res.in and created rule as below.

 

Policy :--

 

Source Zone : trust

Source user :- abc

Destination Zone :- Untrust(internet)

Destination :-  any

Port : 22

url category :- *. ncra.tifr.res.in

Application: SSH

Profile :- None

Action :- Allow

 

However it is not working.

Note :- Customer  dont have fqdn he provided *.ncra.tifr.res.in

 

So I wanted to know that  *.ncra.tifr.res.in custom category not work for application other than web browsing and ssl?

 

 

Thanks

Dhananjay

Hi @DhananjayBhakte 

Custom URL categories only work for http and TLS traffic - not only for apps web-browsing and ssl as there are quite a few more that are based on http/tls traffic - but at least for ssh you cannot use a custom URL category. 

L2 Linker

Thanks Cyber Elite I Got it now......... 🙂 

  • 1 accepted solution
  • 12637 Views
  • 11 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!