Definitions

The definitions view presents the scaffolds associated with configuring mechanisms to identify applications and WAN targets.

The rXg identifies applications by traffic characteristics and WAN targets by IP address or domain name. Identified applications and WAN targets are used in many facts of the policy enforcement engine.

For example, when used with bandwidth queues, application identification is useful for reducing the priority of bulk transfer of data over FTP and NNTP and increasing the priority of interactive applications such as web surfing. WAN targets may be used with bandwidth queues to restrict the utilization of social networking websites and/or guarantee the bandwidth to video on demand servers.

WAN targets are in many other facets of the policy enforcement engine. For example, WAN targets are used as whitelists to enabled unfettered access to certain websites when forced browser redirection to a captive portal is enabled. In addition, WAN targets are used to select destinations for link affinity when an rXg is deployed in a link control scenario.

Applications

An entry in the applications scaffold defines a set of ports that are considered by the rXg to be a singular logical group for policy enforcement.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The protocol field configures this application definition to match to a particular class of transport. In most cases, a given application will only transport over only one TCP, UDP or ICMP, not

The destination ports and source ports fields specify the ports that are used to identify the application defined by this record. Multiple ports and ranges of ports are specified by using these operators:

!=x All ports not equal to the specified value. For example, !=80 matches all ports other than 80. <x and <=x All ports less then and less than or equal to the specified value. For example, <1024 matches all ports less than 1024 (i.e., 1 to 1023 inclusive) and <=1024 matches all ports less or equal to 1024 (i.e., 1 to 1024 inclusive). >x and >=x All ports greater than and greater than or equal to the specified value. For example, >40000 matches all ports greater than 40000 (i.e., 40001 to 65535 inclusive) and <=40000 matches all ports greater than or equal to 40000 (i.e., 40000 to 65535 inclusive). x-y and x:y All ports within the range specified by the numbers on either side of the operator including boundaries. For example, 5900-5909 and 5900:5909 are two ways to specify ports 5900 to 5909 inclusive. x><y All ports within the range specified by the numbers on either side of the operator excluding boundaries. For example 1025><1030 specifies ports 1026 to 1029 inclusive. x<>y All ports except those specified by the numbers on either side of the operator. x,y Multiple port specifications may be included in a single field by separating them with commas. For example, `8080-8090, 9080-9090,

=9300`

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

WAN Targets

WAN targets define WAN IP addresses and DNS entries that are to be considered as a single logical group for the purposes of policy enforcement.

The targets field configures the list of WAN IPs and/or DNS entries that are members of this WAN target. Any combination of dotted quad IP addresses and DNS names is valid. It is recommended that each WAN target contain either all IP addresses or all DNS names for clarity.

Using DNS names reduces the performance of the system due to the need to perform DNS lookup. Use IP addresses whe possible.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

DPI Signatures

An entry in the DPI Signatures scaffold specifies a set of deep packet inspection rules that are used to identify and classify of end-user traffic.

The rules field contains the deep packet inspection specifications that are used to identify the end-user traffic. Rules are specified using the Snort rule format. The rXg is designed to be compatible with most Snort rulesets that are commonly available for download. For example, the Sourcefire Vulnerability Research Team publishes a list of Snort rules that identify common attacks.

The rXg requires that rules follow a few additional specifications in addition to the Snort grammar:

The alert action must be specified. The log and pass actions will not have any affect when used with the rXg. In other words, any rule that does not begin with the alert idiom will be ignored when used with the rXg.

The sid idiom (Snort rule ID) is required for each and every rule. Furthermore no two rules may have the same sid. Ensure that rules abide by the Snort sid conventions to prevent sid conflict. Values of sid less than one million are reserved for "official" rules. Bleeding Snort publishes rules starting at sid two million. Entirely new custom rules should start at sid nine million.

The msg idiom is used by the rXg for logging. For example, when DPI signatures are used with triggers, the string specified by the msg idiom is used to populate the reason field.

Here is a simple example rule that checks to see if a node transmits 10 emails (via port 25) in the past 60 seconds:

alert tcp $HOME_NET any -> any 25 (msg:"possible spammer";
content:"rcpt to\:"; nocase; flow:to_server, established;
threshold:type both, track by_src, count 10, seconds 60; sid:9000000;
rev:1;)

Here is a another example rule that checks to see if a node opens more than 10 SSH connections (via port 25) in the past 60 seconds:

alert tcp any any -> any 22 (msg:SSH incoming; flow:stateless;
flags:S+; threshold:type both, track by_src, count 10, seconds 60;
sid:9000001; rev:1;)

Nodes that exhibit such behavior are likely to be zombies that are transmitting spam. The above rule is intended to be used in a DPI signature linked to a policy that is associated with throttling via bandwidth queues or quarantine via captive portal to prevent upstream spamming.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Remote DPI Signatures

An entry in the Remote DPI Signatures scaffold configures the rXg for automatic download of deep packet inspection signatures that are used to identify and classify of end-user traffic from a third-party website.

The categories field allows the operator to choose from one or more groups of predefined signatures present on the third-party server. This field is only useful when the URL of this remote DPI signature refers to a gzipped tarball archive. The signatures present in the archive are presumed to be organized by file name. Each file should contain signatures that are relevant to the name of the file.

The SID whitelist field enables the operator to exclude specific rules from being used. This feature is typically used to exclude overly aggressive rules and thus reduce the possibility of false positives. Consider the following rule from the Snort emerging threats list:

emerging-p2p.rules:alert udp $HOME_NET 1024:65535 -> $EXTERNAL_NET 1024:65535 (msg:"ET P2P Edonkey Publicize File"; dsize:>15; content:"|e3 0c|"; depth:2; reference:url,www.giac.org/certified_professionals/practicals/gcih/0446.php; reference:url,doc.emergingthreats.net/bin/view/Main/2003310; classtype:policy-violation; sid:2003310; rev:3;)

The example rule shown above is known to occasionally trip false positives with Skype file sharing. Listing 2003310 into the SID whitelist field causes the rule to be ignored. Multiple SIDs may be listed in the SID whitelist to tell the DPI engine to ignore more than one rule in the remote set.

When a remote DPI signature record is first created, the categories field will be empty. Once the signatures have been downloaded and extracted for the first time, the names of the files will then appear in this field. After creating a remote DPI signature it is necessary to edit the record and select the desired categories in order for proper operation. Initial download time (and hence, population of the categories field depends upon the size of the archive file as well as the speed of the network connection between the server addressed by the URL.

The URL field contains the URL of the file that the rXg will download. The target file is expected to be in one of two formats: .tar.gz archive or a .txt plain text file. If the file is a gzipped tarball archive (.tar.gz), it is expected to extract multiple files named by category, each of which contains DPI signatures. If the file is plain-text, it is expected that the file is simply a file of the the DPI signatures. The rXg supports DPI signatures formatted for Snort 2.9. Well known remote DPI signature repositories include the official Snort rules and the Snort emerging threats list.

The frequency field specifies the download interval. Some sites have terms of use that specify appropriate download intervals. Please check the remote site terms and conditions carefully before using.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Content Filter Lists

Entries in the content filter lists scaffold are used to define sets of domain names and URLs that are to be blocked or passed by the rXg content filter. Each content filter list record should store a list of domains, wildcards, or URLs that are similar in nature for organizational purposes. Multiple content filter lists may be used simultaneously in a single content filter enforcement.

The category field is used to store a short phrase that is meant to help the end-user understand the reason why the URL is being blocked. The text in this field is presented on the access denied page on the captive portal. For example, if the list includes domains and URLs that refer to online casinos, the phrase "gambling" would be appropriate for the category.

The list field contains the set of entries that comprise this content filter list. When this content filter list is associated with a content filter enforcement, HTTP requests that match entries in this list will be denied. Valid entries include domain names (e.g., somedomain.com) as well as URL fragments (e.g., somedomain.com/somepath/).

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Remote Content Filter Lists

Entries in the remote content filter lists scaffold are used to configure the parameters needed to periodically download third party maintained lists. The de facto standard list format is a compressed archive (.tar.gz) file that extracts into a series of subdirectories named by blocking category. Each entry in this scaffold configures the periodic download of a compressed archive (.tar.gz) file. Multiple archive files may be used in a single content filter policy enforcement.

The categories field allows the operator to choose from one or more groups of URLs and/or domains to include in this remote content filter list definition. This field is only useful when the URL of this remote content filter list refers to a gzipped tarball archive. The names of subdirectories present in the archive are presumed to be the names of blocking categories and show up in this field.

When a remote content filter list is created, this field will be empty. Once the list is downloaded and extracted for the first time, the subdirectories will then appear in this field. After creating a remote content filter list it is necessary to edit the record and select the desired categories in order for proper operation. Initial download time (and hence, population of the categories field depends upon the size of the archive file as well as the speed of the network connection between the server addressed by the URL.

When Custom is selected in the Provider field it allows the operator to specify a custom URL to a list maintained by the operator or another source.

The URL field contains the URL of the file that the rXg will download. The target file is expected to be in one of two formats: .tar.gz archive or a .txt plain text file. If the file is a gzipped tarball archive (.tar.gz), it is expected to extract multiple subdirectories named by category, each of which contains a "urls" file containing a list of specific URLs to list, and/or a "domains" file containing a list of domains (i.e., entire sites) to list. If the file is plain-text, it is expected that the file is a list of domains and URLs to list. The rXg supports lists formatted for ufdbGuard,DansGuardian and SquidGuard. Well known providers include URLfilterDB, Shalla Listand Squidblacklist.org.

The frequency defines the periodicity with which the rXg will download the list archive file from the URL specified. The request to download a new remote content filter list occurs immediately after the create button is clicked. The periodicity of subsequent downloads are determined by the value of specified in this field. The downloading of subsequent updates will always occur between 4 and 5 AM local time.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.