--- title: "Security rule match criteria" canonical: "https://docs.aryaka.com/space/KNOW/1275002907/Security%20rule%20match%20criteria" format: markdown --- Aryaka offers Basic Firewall , NGFW-SWG , Anti-Malware , IPS , CASB , and DLP to provide organizations a high level of control over network security and routing. Each of these security offerings include security engines that allow you to configure security rules to control network traffic. Each security engine includes its own collection of match criteria that you can use to identify traffic when configuring security rules. This document describes each type of match criteria. Zones A zone is a configurable network boundary that separates devices at a site or that access a site. Aryaka recognizes the following four types of zones: VPN—Segments the WAN into smaller parts for increased security and performance. VPN zones can be configured in multiple locations. A site with an ANAP can have multiple VPN zones; a site without an ANAP can only have one VPN zone. DMZ—Site-specific zone used for guest wireless LAN (WLAN) and other restricted access. A site with an ANAP can have multiple DMZ zones; a site without an ANAP cannot have a DMZ zone. Cloud—Separates traffic to third-party internet-facing security providers (for example, Zscaler) and to the rest of the site. A site (with or without an ANAP) can have multiple cloud zones. Public—Hosts the public-facing interfaces of a site and carries internet-facing traffic. A site (with or without an ANAP) can only have one public zone. These zones can be used as match criteria to identify if traffic is coming from a zone—the source zone —or is going to a zone—the destination zone . To configure a VPN or DMZ zone in MyAryaka, see the Configure zones help topic. A zone can be referenced individually in a rule’s match criteria or it can be grouped along with others as a named asset. To configure a zone asset in MyAryaka, see the Zone assets help topic. The following graphic shows how an individual zone or a predefined zone asset can be used as match criteria when writing a rule: Destination zones can only be matched in the Interzone Firewall rule table. Source zones can be matched in the following rule tables. LAN-Side Basic IPS WAN Routing Interzone Firewall Internet Routing Next Generation Firewall DNS Filtering SaaS Apps Access Control Secure Web Gateway Data Loss Prevention Anti-Malware Advanced IPS Tenant Restriction WAN-Side Basic IPS Aryaka security engines that are designed to function in the outbound direction only allow source zone matching of VPN and DMZ zones. IPs You can write a rule that matches traffic traveling to a destination IP or coming from a source IP . An individual IP can be referenced as a CIDR or you can reference a collection of IPs by creating a named IP asset . To configure an IP asset in MyAryaka, see the IP assets help topic. The following graphic shows a rule that uses an individual IP address as the source IP match, and an IP asset as the destination IP match: Source IP can be matched in all rule tables except DNS Filtering. Destination IP can be matched in all rule tables except the following: DNS Filtering SaaS Apps Access Control Tenant Restriction Ports You can write a rule to match traffic traveling to a destination port or coming from a source port . You can reference an individual port or you can reference a collection of ports by creating a port asset . To configure a port asset in MyAryaka, see the Port assets help topic. The following graphic shows a rule that uses an individual port address as a source port and a port asset as a destination port : Source ports and destination ports can be matched in the following rule tables: LAN-Side Basic IPS WAN Routing Interzone Firewall Internet Routing Next Generation Firewall Advanced IPS WAN-Side Basic IPS Protocols You can write a rule that identifies traffic that uses a specific IP protocol (for example, TCP or UDP). Protocols are configured using their integers. The following table lists some common protocols: Protocol Protocol Number TCP 6 UDP 17 ICMP 1 GRE 47 These can be grouped into a named collection called a protocol asset and used in rules to identify traffic. To configure a protocol asset in MyAryaka, see the Protocol assets help topic. The following graphic shows a rule that uses TCP: Protocols can be matched in the following rule tables: LAN-Side Basic IPS WAN Routing Interzone Firewall Internet Routing Next Generation Firewall Data Loss Prevention Anti-Malware Advanced IPS WAN-Side Basic IPS HTTP headers You can write a rule to match traffic with a specific HTTP header. You can reference one or more HTTP headers by creating an HTTP header asset— a named collection of HTTP headers and associated values. To configure an HTTP header asset in MyAryaka, see the HTTP header assets help topic. The following graphic shows an HTTP Header asset named User-Agents to Intercept Captive Portal used as match criteria in a rule: For all other types of match criteria, when multiple entities are selected for a given match criteria, the default is that the traffic can match any of the listed entities. The HTTP Header match criteria is an exception to this match any condition. When including the HTTP Header match criteria in a rule, you can specify whether traffic must match any or match all HTTP headers included in the rule. HTTP headers can be matched in the following rule tables: Secure Web Gateway Data Loss Prevention Anti-Malware HTTP methods You can write a rule to match traffic with a specific HTTP request method. You can reference one or more HTTP methods, for example, GET and DELETE, when you create a security rule for the Secure Web Gateway security engine. This match criteria is not included in any other security engines. The following graphic shows a rule that permits traffic with the HTTP methods GET, PUT, and POST: Domains You can write a rule that identifies traffic that accesses a specific web domain. Domains can be matched in a rule as follows: Aa an individual domain, for example, http://www.acme.com . As a domain that matches a condition. For example, if www.acme.* is specified, it matches http://www.acme.com , www.acme.org , and http://www.acme.net . As a domain asset by specifying its user-defined name. A domain asset is a named collection of fully qualified domain names like http://www.food.com , http://www.acme.com , and www.factotum.org . To configure a domain asset in MyAryaka, see the Domain assets help topic. The domain as a match criteria does not include the complete URL but just the hostname portion that identifies the service on the server being accessed. Domains can be matched in the following rule tables: DNS Filtering Next Generation Firewall Data Loss Prevention Anti-Malware Advanced IPS Tenant Restriction The following graphic shows three domains used as match criteria in a rule: URLs You can write a rule that identifies traffic that accesses a resource on a specific web URL. URLs can be matched in a rule as follows: As an individual URL, for example, www.abc.com/resource . As a URL that matches a condition. For example, if www.abc.com/resource/*.jpg is specified, it matches all jpg-formatted images hosted there. As a URL asset by specifying its user-defined name. A URL asset is a named collection of fully qualified URLs like www.abc.com/resource , www.foo.com/accounting/expenses.xls , and www.factotum.org/members/patti_smith.html . To configure a URL asset in MyAryaka, see the URL assets help topic. URLs can be matched in the following rule tables: Secure Web Gateway Data Loss Prevention Anti-Malware Advanced IPS Tenant Restriction The following graphic shows a URL asset named Images on CNN used as match criteria in a rule: Web categories You can write a rule to block traffic that is identified as belonging to a specified web category. The web category determination can be performed on the domain or the URL being accessed. Aryaka integrates with Webroot to recognize approximately 80 categories including Malware Sites, Phishing, Proxy Avoidance and Anonymizers, Spam URLs, Spyware and Adware, Bot Nets, and Keyloggers. Web categories can be referenced individually in a rule or they can be grouped into a web category asset that is then referenced in the rule. To configure a web category asset in MyAryaka, see the Web category assets help topic. Domain categories can be used as match criteria in the following rule tables: DNS Filtering Next Generation Firewall URL categories can be used as match criteria in the following rule tables: Secure Web Gateway If Webroot can not map a domain or URL to a web category or if the classification engine experiences a failure, the category is identified as Unclassified. You can write a rule that specifies what the security engine should do with Unclassified traffic. The Unclassified category is matched in the following tables: DNS Filtering Next Generation Firewall Secure Web Gateway Without this rule, the default rule in the rule table is consulted and its action is implemented. Each table has a different default rule. Reputation scores You can write a rule that blocks traffic based on its reputation score. The reputation score is based on the domain, URL, or SaaS application being accessed. Aryaka integrates with Webroot to obtain reputation scores. A valid reputation score range spans 1-100 where 1 is a poor score and a 100 is a good score. A rule may be written to drop traffic if its score falls in a low range such as 1-20. These ranges can be written into a rule or a range may be predefined as a reputation score asset . To configure a reputation score asset in MyAryaka, see the Reputation score assets help topic. The following graphic shows a rule that matches traffic in the range 1–20 and also a reputation score asset named Suspicious , which matches traffic in the range 21–40: Domain Reputation Score can be used as a match criteria in the following rule tables: DNS Filtering Next Generation Firewall URL Reputation Score can be used as a match criteria in the following rule tables: Secure Web Gateway SaaS Application Reputation Score and SaaS Application Organization Reputation Score can be used as match criteria in the SaaS Apps Access Control rule table. If Webroot cannot identify the specified reputation score, the flow is considered to belong to the Unclassified category. If no rule exists with Unclassified specified, the default rule is consulted and its rule action is implemented. Users and user groups You can write a rule that identifies traffic from the following types of users and user groups: Enterprise users Enterprise user groups User assets User group assets The enterprise users and groups that you can include in a user and group assets are different from those configured for MyAryaka in Access control . MyAryaka can be configured to learn users and user groups from your enterprise’s authenticator (for example, Active Directory). These users and user groups can then be referenced in a rule. In addition to including individual users and user groups in a rule, users can be collected into a named asset called a user asset. Similarly, user groups can be collected into a named asset called a user group asset . To configure a user or user group asset in MyAryaka, see the User assets and User group assets help topics. The following graphic shows all four types of users in a rule’s match criteria: Users and groups can be matched in the following rule tables: Next Generation Firewall SaaS Apps Access Control Secure Web Gateway Data Loss Prevention Anti-Malware Advanced IPS Tenant Restriction Destination sites You can write a rule to match traffic traveling to a destination site . You can reference an individual site or you can reference a collection of sites by creating a site class asset . To configure a site class asset in MyAryaka, see the Site class assets help topic. Destination sites can be matched in the following rule tables: Secure Web Gateway Data Loss Prevention Anti-Malware Destination networks You can write a rule to match traffic traveling to a destination networks . You can reference one or more individual networks when creating a rule. Destination networks can be matched in the following rule tables: Next Generation Firewall Secure Web Gateway Data Loss Prevention Anti-Malware Match rules You can write a rule to match traffic traveling using specific match rules. You can reference a match rule by creating a match rule asset —a named collection of network identifies including protocol, source IP, source port, destination IP, destination port, and TOS. To configure a match rule asset in MyAryaka, see the Match rule assets help topic. Match rules can be used in the following rule tables: WAN Routing Interzone Firewall Internet Routing Geolocations You can write a rule to match traffic traveling to a destination geolocation or coming from a source geolocation . You can reference an individual geolocation (a country or continent) or you can reference a collection of geolocations by creating a geolocation asset . To configure a geolocation asset in MyAryaka, see the Geolocation assets help topic. Geolocations can be matched in the following rule tables: Interzone Firewall Next Generation Firewall Secure Web Gateway Anti-Malware Applications You can write a rule that blocks traffic that has been identified as belonging to a discovered application, a managed application, or a group of managed applications. The following graphic shows a rule that matches all three application types: Applications can be matched in the following rule tables: WAN Routing Interzone Firewall Internet Routing Next Generation Firewall Secure Web Gateway Data Loss Prevention Anti-Malware Advanced IPS SaaS applications You can write a rule to match SaaS application traffic based on the following criteria: SaaS application (for example, Facebook, Instagram, or Gmail) SaaS application category (for example, Social Media or Streaming Media) SaaS application suite (for example, Microsoft 365 or Google Workspace) SaaS application organization (for example, Meta Platforms, Inc., Alphabet Inc., or Microsoft Corporation) You can reference an individual SaaS application, category, suite, or organization, or you can reference a collection by creating an asset . To configure an asset for one of the SaaS application match criteria in MyAryaka, see the Asset Management help topic. These SaaS application match criteria can all be used in the SaaS Apps Access Control rule table, while all except SaaS application category can be used by the Data Loss Prevention and Tenant Restriction rule tables. SaaS application classification You can write a rule to match traffic with a specific SaaS application classification. You can classify SaaS applications as sanctioned or unsanctioned in MyAryaka (see the Configure SaaS Apps Classification topic for details). The SaaS Application Classification match criteria then allows you to match traffic that is sanctioned, unsanctioned, or unclassified when creating a SaaS Apps Access Control rule. User functions You can write a rule to match traffic with a specific SaaS application user function, for example Login, Upload, or Like. You can reference an individual user function or you can reference a collection of user functions by creating a SaaS application user function asset . To configure a SaaS application user function asset in MyAryaka, see the SaaS application user function assets help topic. User functions can be matched in the following rule tables: SaaS Apps Access Control Data Loss Prevention Tenant Restriction Schedules You can write a rule to match traffic during specific time periods. You can reference a schedule by creating a schedule asset —a named collection of dates, days of the week, and times. To configure a schedule asset in MyAryaka, see the Schedule assets help topic. Schedules can be matched in the following rule tables: LAN-Side Basic IPS Next Generation Firewall DNS Filtering SaaS Apps Access Control Secure Web Gateway Data Loss Prevention Anti-Malware Advanced IPS Tenant Restriction WAN-Side Basic IPS In this topic