Components of a QoS policy

Applications — These are the various software programs that the Sensor can detect. The Manager derives the list of applications from the signature set. You cannot modify the list of available applications.

Important

If Trellix Advanced Research Center deprecate an application that you have used in a QoS policy, a fault message of warning severity is raised. You will then have to delete those rules from the policies or modify them; if not, signature set push to Sensors will fail.

Application on Custom Port — You can use rule object to detect applications when they are communicated over specific ports. For example, you might want the Sensor to detect FTP, when it is over port 2021.

Application Group — If the pre-defined Application Groups do not meet your requirements, you can create one. You create an Application Group to combine more than one application and Application on Custom Port rule objects. Typically, you create an Application Group for those applications that you want the Sensor to handle in a similar fashion. For example, you can combine all applications related to Internet games to form one Application Group. You can group up to 10 items in an Application Group.

Note

You can combine Application and Application on Custom Port rule objects to form an Application Group. You cannot include Application Group within another Application Group.

Country — The Country rule object enables you to identify traffic based on the source or destination country for QoS. The Sensor identifies the traffic originating or destined to these countries based on the CIDRs mapped to the countries.

The country-to-CIDRs mapping information is sourced from the geolocation database of Digital Envoy. You cannot modify or update this list of countries manually. Trellix updates this list of country-to-CIDRs mapping through signature sets. Use the status command in a Sensor's CLI to check if the geolocation database is present on the Sensor.

Note

If the Manager and Sensor are on software versions prior to 10.1 Update 7, it is recommended to upgrade them to later versions to continue receiving the updated geolocation databases. For more information, refer to KB95636. Always ensure to maintain the latest software versions of the Manager, Sensor, and Signature Sets.

IPv4 Endpoint — You can create a list of source and destination IPv4 addresses that you want to use in a QoS rule. You can specify up to 10 addresses in a rule object.

IPv6 Endpoint — You can create a list of source and destination IPv6 addresses that you want to use in a QoS rule. You can specify up to 10 addresses in a rule object.

Host DNS Name — You can create the list of source and destination host names that you want to use in a QoS rule. For example, you can create a Host DNS Name rule object for facebook.com, faceparty.co.uk, and ibibo.com. You can add 10 Host DNS Names in a rule object. The Sensor contacts the DNS servers that you configure in the Name Resolution page to resolve these names to IP addresses. To go to the Name Resolution page of a Sensor, under the Devices tab, select <Admin Domain Name> → Devices → <Device Name> → Setup → Name Resolution.

Important

The Sensor uses only UDP and never falls back to TCP for DNS queries even if the DNS server forces for TCP.

IPv4 address range — You can create the list of IPv4 addresses to use in a QoS rule. In the rule, you can specify an IPv4 address range as the source or destination of traffic. For example, you may want to apply a rule to traffic from IPs ranging from 10.1.1.1 to 10.1.1.25. You can specify up to 10 ranges in a rule object.

IPv6 address range — You can create the list of IPv6 addresses to use in a QoS rule. In the rule, you can specify an IPv6 address range as the source or destination of traffic. You can specify up to 10 ranges in a rule object.

IPv4 Network — You can create a list of IPv4 CIDRs to use in a QoS rule. In the rule, you can specify a CIDR as the source or destination of traffic. For example, you might want to apply a rule on the traffic targeted for 172.16.225.0/24 network. The three reserved IPv4 ranges according to RFC 1918 are provided as default networks. You can specify up to 10 CIDRs in one rule object.

IPv6 Network — You can create a list of IPv6 CIDRs to use in a QoS rule. In the rule, you can specify a CIDR as the source or destination of traffic. You can specify up to 10 CIDRs in one rule object.

Network Group — You can combine one or more Country, Host IP, Host Name, IP range, or Network to form a Network Group. For example, you can combine all the North American countries and multiple IP ranges to form a Network Group rule object. You can specify up to 10 items in one Network Group rule object.

Note

The Network Group rule object that you create can contain either IPv4-based rule objects or IPv6-based rule objects. You cannot combine IPv4 and IPv6 rule objects in one Network Group rule object.

Finite Time Period — You can configure the Sensor to enforce a QoS rule continuously just for a specific time period. For example, you might want to enforce a rule from 9 am on June 10 to 10 am on June 11. For this, you need to create a Finite Time Period rule object specifying the start time and date along with the end time and date. The start and end time are both inclusive. You can specify only one Finite Time Period rule object in a QoS rule. Time-based rules are implemented using the local time zone of the corresponding Sensor.

Recurring Time Period — This rule object enables you to enforce a QoS rule at a certain frequency. For example, you can enforce a rule from 9 am to 5 pm on all weekdays. To enforce a rule just once, use the Finite Time Period rule object.

When you use a time-based rule object, make sure you have configured the corresponding Time Zone. Time-based rules are implemented using the local time zone of the corresponding Sensor. Note that the Sensor automatically factors in the daylight savings time, where applicable. GMT is the default Time Zone in the Manager.

Recurring Time Period Group — You can group up to 10 Recurring Time Periods to form a Recurring Time Period Group rule object.

Note

You can use the Finite Time Period rule object along with Recurring Time Period and Recurring Time Period Group rule objects. In such a case, the Finite Time Period takes precedence. Also, for the Sensor to check for that QoS rule, the Finite Time Period and at least one Recurring Time Period must be active.

Service — To classify traffic based on the IP protocol, ICMP codes, or the TCP/UDP port numbers, use the Service rule object. You can create Service rule objects or use the default ones. The well-known services on standard TCP and UDP ports, as well as ICMP codes are pre-defined. For example, telnet is predefined as TCP on port 23. Similarly, ICMP codes such as ICMP echo reply and ICMP request are pre-defined.

Note

ICMP-Fragmented, TCP-Fragmented, and UDP-Fragmented Service rule objects are not relevant for QoS.

When you create a Service rule object, the options are to specify the protocol number, TCP port, or UDP port. You can define only one IP protocol specification per rule object.

Note

For QoS rules that use Service rule objects, the Sensor factors in any non-standard ports that you have configured for IPS. For example, if you have specified port 2023 as the non-standard port for FTP, and if you have used the FTP Service rule object in a rule, then the Sensor considers FTP on both ports 21 and 2023.

For certain traffic, you can use more than a type of rule object. For example, for FTP and HTTP, you can use the Application rule object or the Service rule object. If you use the Application rule object, the Sensor does not consider the port number when detecting the traffic, and relies only on the application signatures. This means that the Sensor can detect a protocol regardless of the port used in case of Application rule objects. If you use the Service rule object, the port number matters when detecting a protocol. The Sensor considers all the standard ports as well as non-standard port numbers that you have defined in the Non-Standard Ports page.

In case of Service rule object, the Sensor can classify the traffic using even the SYN packet. In case of Application rule object, the Sensor can classify the traffic only after the three-way handshake. This is because, only after the handshake, the Sensor identifies the application.

Note

A Sensor processes the QoS rules in a top-down fashion. So, if you want to classify traffic based on Services, define those rules high up in the policy.

Note the following if you use classic QoS policies:

Service Group — You can group the services that you want to be handled in a similar manner. This enables you to easily manage your QoS policies. You can group up to 10 services in one Service Group rule object. You cannot add Service Range objects in a Service Group.

Service Range — You can define a Service Range rule object by defining the TCP or UDP port range. You can define up to 10 services ranges in one rule object. You can combine TCP ranges and UDP ranges in a Service Range rule object. Service Range is available only for QoS policies.

Note

The Service Range rule object is available only for QoS policies.