CFS 4.0: How does URI Expression work

Description

Feature/Application:

From CFS 4.0, URI list object is used to do URL/Domain matching. It contains a list of customized URI and asterisk wildcard is supported in the URI expression. This article will give an introduction to the configuration and matching rules of CFS URI list objects.

Resolution

Configuration

Image

Each URI contains up to 16 tokens, which are separated by punctuation ".", "/" and "|"

The token is a sting composed of characters: 0-9a-zA-z$-_+!'(),

The length of each token should not be longer than 64 characters. The asterisk wildcard "*", as a special token, is able to represent one or more valid tokens.

And IPv4 and IPv6 address string are also supported in URI Expression as well.

Example of valid URIs:
news.example.com
news.example.com/path
news.example.com/path/abc.txt
news.*.com/*.txt
10.10.10.10
10.10.10.10/path
[2001:2002::2003]/path
[2001:2002::2003:*:2004]/path/*.txt

Note: Since wildcard ‘*’ here represents one or more tokens, "example*.com" or "exa*ple.com" is invalid. And continuous ‘*’ like "example.*.*.com" is also invalid.

Matching Rules

Unlike generic string matching, the match process of CFS URI List Object is based on tokens. A valid tokens sequence is composed of one or more tokens, jointed by specific flag, like ‘.’ or ‘/’. A URL can be deemed as a tokens sequence. E.g. URI "www.example.com" is deemed as tokens sequence of "www", "example" and "com", jointed by ‘.’.
Generally, if a URI contains one of URI (tokens sequence) in the CFS URI list object, then the list object matches that URI. Following are some cases to explain the matching rules in detail.

Case 1: Normal Matching

If there is a URI "example.com" in the list object, then that object can match URI like [<tokens sequence>(.|/)]example.com[(.|/)<tokens sequence>]. Following are some examples:
"example.com"
"www.example.com"
"example.com.uk"
"www.example.com.uk"
"example.com/path"

It can’t match URI like "specialexample.com", since "specialexample" is deemed as a difference token against "example".

Case 2: Wildcard matching

Wildcard matching is supported. A wildcard ‘*’ here represents a valid tokens sequence. 
If there is a URI "example.*.com" in the list object, then that list object can match URI like "[<tokens sequence>(.|/)]example.<tokens sequence>.com[(.|/)<tokens sequence>]". Following are some examples:
"example.exam1.com"
"example.exam1.exam2.com"
"www.example.exam1.com/path"

It can’t match URI like "example.com", since wildcard ‘*’ represents a valid token sequence, and a valid tokens sequence is composed of one or more tokens, jointed by specific flag, like ‘.’ or ‘/’.

Case 3: IPv6 Address Matching

IPv4 address can be deemed as a normal tokens sequence, while IPv6 address string need to be handled specially.

If there is a URI "[2001:2002::2008]" in the list object, then that list object can match URI like [2001:2002::2008][/<tokens sequence>]. Following are some examples:
"[2001:2002::2008]"
"[2001:2002::2008]/path"
"[2001:2002::2008]/path/abc.txt"

If there is a URI "[2001:2002:*:2008]/*/abc.mp3" in the list object, then that list object can match URI like [2001:2002:<tokens sequence>:2008]/<tokens sequence>/abc.mp3. Following are some examples:
"[2001:2002:2003::2007:2008]/path/abc.txt"
"[2001:2002:2003:2004:2005:2006:2007:2008]/path/path2/abc.txt"

 

Related Articles

  • SonicOS 8.1.0 FAQ
    Read More
  • SonicWall GEN8 TZs and GEN8 NSas Settings Migration
    Read More
  • Getting started with SonicWall firewalls
    Read More
not finding your answers?