Components of Firewall policies

User — These are the Windows AD users currently logged on to your network. The Manager gathers this list from Trellix Logon Collector and provides it to the Sensor.

User Group — These are the user groups of the currently logged on users. The Manager gathers this information from Trellix Logon Collector and provides it to the Sensor.

Note

You cannot create, modify, or delete Users or User Groups in the Manager. You can view these rule objects only on the Access Rules tab of the Firewall page. Regarding Users, you cannot view the entire list even in the Firewall page; you can query for the required users when defining the access rules. You cannot view the User or User Group rule objects in the Rule Objects page.

Application — 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. Applications are relevant only to advanced Firewall policies.

Important

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

Application on Custom Port — You can use this rule object to detect applications when they are communicated over non-standard ports. For example, you might want the Sensor to detect FTP, when it is over port 2021. Application on Custom Port is relevant only to advanced Firewall policies.

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 way. 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. Application Group is relevant only for advanced Firewall policies.

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 allow or block traffic based on the source or destination country. The Sensor identifies the traffic originating or destined to these countries based on the CIDRs mapped to the countries. Country is relevant only for advanced Firewall policies.

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 in 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 Firewall rule. You can specify a maximum of 140000 IPv4 addresses in a rule object based on the Sensor model. If you have enabled XFF header parsing in your Sensor, you will be able to use the original source IP address of the for HTTP traffic.

Note

If you are using a Manager which is on or before version 10.1.7.55 and a Sensor which is on or before 10.1.5.153, you can add up to 10 IPv4 addresses in a rule object.

IPv6 Endpoint — This is similar to the IPv4 Endpoint rule object but applies only to advanced policies.

Host DNS Name — You can create the list of source and destination host names that you want to use in a Firewall rule. The Sensor contacts the DNS servers that you configure to resolve these names to IP addresses. For example, you can create a Host DNS Name rule object for facebook.com, faceparty.co.uk, ibibo.com. You can add a maximum of 5000 Host DNS Names in a rule object. Host DNS Name applies only to advanced Firewall policies.

Important

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

Note

If you are using a Manager which is on or before version 10.1.7.55 and a Sensor which is on or before 10.1.5.153, you can add up to 10 Host DNS Names in a rule object.

IPv4 Address Range — You can create the list of IPv4 address ranges to use in a Firewall 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. This rule object applies only to advanced Firewall policies. You can specify a maximum of 20000 ranges in a rule object. If you have enabled XFF header parsing in your Sensor, you will be able to use original source IP addresses for HTTP traffic.

Note

If you are using a Manager which is on or before version 10.1.7.55 and a Sensor which is on or before 10.1.5.153, you can add up to 10 address ranges in a rule object.

IPv6 Address Range — This is similar to the IPv4 Address Range.

IPv4 Network — You can create a list of IPv4 CIDRs to use in a Firewall 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 a maximum of 140000 CIDRs in one rule object.

Note

If you are using a Manager which is on or before version 10.1.7.55 and a Sensor which is on or before 10.1.5.153, you can add up to 10 CIDRs in a rule object.

IPv6 Network — Similar to IPv4 Network but applies only to advanced Firewall policies. Also, there are no predefined IPv6 Network rule objects in the Manager.

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. This rule object applies only to advanced Firewall policies. You can specify up to 10 items in one Network Group rule object.

Note

You cannot combine IPv4 and IPv6 based rule objects in the same Network Group rule object. Note that Country and Host DNS are IPv4-based.

Finite Time Period — You can configure the Sensor to enforce an access rule continuously just for a specific time period. For example, you might want to enforce a rule from 9 am on June 10 of this year to 10 am on June 11 of this year. 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. Finite Time Period applies only to advanced Firewall policies. You can specify only one Finite Time Period rule object in a Firewall access rule.

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. The Sensor automatically factors in the daylight savings time, if applicable. GMT is the default Time Zone in the Manager.

Recurring Time Period — You can repeatedly enforce a Firewall rule at certain frequencies of time. For example, you can enforce a rule from 9 am to 5 pm on all weekdays. Use this rule object to repeatedly enforce a rule. 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. Recurring Time Period applies only to advanced Firewall policies.

Recurring Time Period Group — You can group up to 10 Recurring Time Periods to form a Recurring Time Period Group rule object. Recurring Time Period Group applies only to advanced Firewall policies.

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 access rule, the Finite Time Period and at least one Recurring Time Period must be active.

Service — To restrict 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. When you create a Service rule object, the options are to specify the protocol number, TCP port, or UDP port. For custom ICMP codes, you need to specify the IP protocol number and the ICMP code in the port field. You can define only one IP protocol specification per rule object.

Note

For access 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 protocols, 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 a 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 drops even the SYN packet. In case of Application rule object, the Sensor drops the traffic only after the three-way handshake; only after the handshake, the Sensor identifies the application.

Note

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

Note the following if you use classic Firewall 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 Firewall policies. Service Group is relevant only for advanced Firewall policies. You can group up to 10 services in one Service Group rule object.

Note

Service Range is applicable only to QoS policies.