# Options for stateful rules in Network Firewall Stateful rule options A stateful rule group is a rule group that uses Suricata compatible intrusion prevention system (IPS) specifications. Suricata is an open source network IPS that includes a standard rule-based language for stateful network traffic inspection. When you create a Network Firewall stateful rule group from Suricata compatible rules, you can provide the rules to the rule group creation operation in one of the following ways: + **Standard, simple rule group specification** – With this option, Network Firewall translates your specification into Suricata compatible rules and then passes the resulting rule strings to Suricata for processing. + **Domain list rule specification** – With this option, Network Firewall translates your rule specification into Suricata compatible rules and then passes the resulting rule strings to Suricata for processing. + **Rule strings that are written in Suricata compatible syntax** – When you use this option, Network Firewall passes your rule strings to Suricata for processing. The sections that follow provide details for each of these options. **Topics** + [ # Standard stateful rule groups in AWS Network Firewall ](stateful-rule-groups-basic.md) + [ # Suricata compatible rule strings in AWS Network Firewall ](stateful-rule-groups-suricata.md) + [ # Stateful domain list rule groups in AWS Network Firewall ](stateful-rule-groups-domain-names.md) + [ # IP set references in Suricata compatible AWS Network Firewall rule groups ](rule-groups-ip-set-references.md) + [ # Geographic IP filtering in Suricata compatible AWS Network Firewall rule groups ](rule-groups-geo-ip-filtering.md) + [ # URL and Domain Category Filtering in Suricata compatible AWS Network Firewall rule groups ](rule-groups-url-filtering.md) # Standard stateful rule groups in AWS Network Firewall Standard stateful rule groups AWS Network Firewall supports easy entry for standard stateful rules for network traffic inspection. The match criteria for this stateful rule type is similar to the Network Firewall stateless rule. All rule groups have the common settings that are defined at [Common rule group settings in AWS Network Firewall](rule-group-settings.md). **General settings** A stateful basic rule has the following general settings. + **Action** – Defines how Network Firewall handles a packet that matches the rule match settings. Valid values are pass, drop, reject, and alert. For more information about actions, see [Defining rule actions in AWS Network Firewall](rule-action.md). **Match settings** A basic stateful rule has the following match settings. These specify what the Network Firewall stateful rules engine looks for in a packet. To be a match, a packet must satisfy all of the match settings in the rule. + **Protocol** – Transport protocol. Choose the protocol that you want to inspect. For all protocols, you can use `IP`, because all traffic on AWS and on the internet is IP. + **Source IP** – Source IP addresses and ranges. If specified, a packet must come from a source address that's included in this list in order to match. + **Source port** – Source ports and port ranges. If specified, a packet must have a source port that's included in this list in order to match. + **Destination IP** – Destination IP addresses and ranges. If specified, a packet must have a destination address that's included in this list in order to match. + **Destination port** – Destination ports and port ranges. If specified, a packet must have a destination port that's included in this list in order to match. + **Traffic direction** – Direction of traffic flow. Valid settings are `Any` and `Forward`. `Forward` matches packets whose origination matches the rule's source settings and whose destination matches the rule's destination settings. `Any` matches the forward match, and also matches packets whose origination matches the rule's destination settings, and whose destination matches the rule's source settings. + **Rule options** – Define the specifics of the rule, in keyword, settings pairs. **Note** The console doesn't currently allow entry of rule options. Rule options are usually required for complete specification of this rule type. If you need to specify rule options, use one of the APIs or AWS CloudFormation. For information, see [StatefulRule](https://docs.aws.amazon.com/network-firewall/latest/APIReference/API_StatefulRule.html) in the *AWS Network Firewall API Reference* and [AWS::NetworkFirewall::RuleGroup StatefulRule](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-networkfirewall-rulegroup-statefulrule.html) in the *AWS CloudFormation User Guide*. For an example rule specification and the Suricata compatible rule that Network Firewall generates from it, see [Stateful rules examples: standard stateful rule groups](suricata-examples.md#suricata-example-basic). # Suricata compatible rule strings in AWS Network Firewall Suricata compatible rule strings When you use this rule group type, you provide match and action settings in a string, in a Suricata compatible specification. Your specification fully defines what the stateful rules engine looks for in a traffic flow and the action to take on the packets in a flow that matches the inspection criteria. All rule groups have the common settings that are defined at [Common rule group settings in AWS Network Firewall](rule-group-settings.md). You can provide your Suricata compatible specification to Network Firewall in rules strings or files, depending on how you're accessing Network Firewall. + **Console** – In the AWS Management Console, provide the rules string in the text box that appears for the stateful rule group option **Import Suricata compatible rules**. For information about using the console to manage your rule group, see [Creating a stateful rule group](rule-group-stateful-creating.md). + **API** – Through the API, you can provide either the rules or the name of the file that contains the rules. In a file, Suricata compatible rules are usually written one rule per line. You provide either the file or the rules string in the `RulesString` field within the `RuleGroup` structure when you create or update the rule group. For information, see [CreateRuleGroup](https://docs.aws.amazon.com/network-firewall/latest/APIReference/API_CreateRuleGroup.html) in the *AWS Network Firewall API Reference*. + **CLI** – Through the CLI, you can provide the rules, the name of a file that contains the rules, or the name of a file that contains the rule group structure in JSON format, with the rules defined in that. The following listing shows the syntax for providing the rules in a file. To use a command like this, substitute in your new rule group name, its calculated capacity, and the JSON rules file name. ``` aws network-firewall create-rule-group --rule-group-name --capacity --type STATEFUL --rules ``` # Stateful domain list rule groups in AWS Network Firewall Stateful domain list rule groupsEnhancements to stateful domain list rule groups You can now use `REJECT` and `ALERT` actions in your stateful domain list rule groups. AWS Network Firewall supports domain name stateful network traffic inspection. You can create allow lists and deny lists with domain names that the stateful rules engine looks for in network traffic. All rule groups have the common settings that are defined at [Common rule group settings in AWS Network Firewall](rule-group-settings.md). ## General settings A domain list rule group has the following general settings. + **Action** – Defines how Network Firewall handles traffic that matches the rule match settings. Valid values for domain rules are `Allow` `Deny`, `Reject`, and `Alert`: + For `Allow`, traffic of the specified protocol type that does not match the domain specifications is denied. + For `Deny`, traffic matching the domain specifications is blocked. Non-matching traffic is allowed to pass. + For `Reject`, traffic matching the domain specifications is blocked and a TCP reset packet is sent back to the source. This option is only available for TCP traffic. + For `Alert`, traffic matching the domain specifications generates an alert in the firewall's logs (when logging is enabled). Then, traffic either passes, is rejected, or drops based based on other rules in the firewall policy. **For firewall policies that use default action ordering** We recommend that you avoid combining `Reject` or `Alert` domain list rule groups with `Allow` domain list rule groups. When this combination of rule groups is defined in a firewall policy that uses default action ordering, the default drop rule added by the `Allow` rule group will take effect before the `Reject` and `Alert` rules. For more information about actions, see [Defining rule actions in AWS Network Firewall](rule-action.md). + **(Optional) `HOME_NET` rule group variable** – Used to expand the local network definition beyond the CIDR range of the VPC where you deploy Network Firewall. For additional information about this setting, see [Domain list inspection for traffic from outside the deployment VPC](#stateful-rule-groups-domain-names-home-net). See the caveats for the `HOME_NET` and `EXTERNAL_NET` settings at [Suricata features that Network Firewall supports with caveatsSupported with caveats](suricata-limitations-caveats.md#suricata-supported-with-caveats). **Note** The console doesn't currently allow entry of all rule group variables. To specify other rule group variables, use one of the APIs or AWS CloudFormation. For information, see [StatefulRule](https://docs.aws.amazon.com/network-firewall/latest/APIReference/API_StatefulRule.html) in the *AWS Network Firewall API Reference* and [AWS::NetworkFirewall::RuleGroup StatefulRule](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-networkfirewall-rulegroup-statefulrule.html) in the *AWS CloudFormation User Guide*. ## Match settings A domain list rule group has the following match settings. These specify what the Network Firewall stateful rules engine looks for in a packet. A packet must satisfy all match settings to be a match. + **Domain list** – List of strings specifying the domain names that you want to match. A packet must match one of the domain specifications in the list to be a match for the rule group. Valid domain name specifications are the following: + Explicit names. For example, `abc.example.com` matches only the domain `abc.example.com`. + Names that use a domain wildcard, which you indicate with an initial '`.`'. For example,`.example.com` matches `example.com` and matches all subdomains of `example.com`, such as `abc.example.com` and `www.example.com`. + **Protocols** – You can inspect HTTP or HTTPS protocols, or both. For HTTPS traffic, Network Firewall uses the Server Name Indication (SNI) extension in the TLS handshake to determine the hostname, or domain name, that the client is trying to connect to. For HTTP traffic, Network Firewall uses the HTTP host header to get the name. In both cases, Network Firewall doesn't pause connections to do out-of-band DNS lookups. It uses the SNI or host header, not the IP addresses, when evaluating domain list rule groups. If you want to inspect IP addresses, to mitigate situations where the SNI or host headers have been manipulated, write separate rules for that and use them in conjunction with or in place of your domain list rules. For examples of domain list specifications and the Suricata compatible rules that Network Firewall generates from them, see [Stateful rules examples: domain list rules](suricata-examples.md#suricata-example-domain-filtering). ## Domain list inspection for traffic from outside the deployment VPC Domain list inspection for traffic from outside the deployment VPC To use domain name filtering for traffic from outside the VPC where you've deployed Network Firewall, you must manually set the `HOME_NET` variable for the rule group. The most common use case for this is a central firewall VPC with traffic coming from other VPCs through a transit gateway. By default, domain list inspection uses a `HOME_NET` that is set to the CIDR range of the VPC where Network Firewall is deployed. Only traffic from that range is passed through the domain list filtering. To filter traffic from outside the deployment VPC, you must provide a `HOME_NET` setting that includes the other CIDR ranges that you want to inspect, along with the CIDR range of the VPC where Network Firewall is deployed. For example, say that the VPC where you deploy Network Firewall has the CIDR range `192.0.2.0/24`. In addition to the traffic for that VPC, you want to filter traffic for two other VPCs that have CIDR ranges `10.0.0.0/16` and `10.1.0.0/16`. You're using a domain list rule group named `domains`. The following command line call retrieves the JSON listing for the rule group: ``` aws network-firewall describe-rule-group --type STATEFUL \ --rule-group-name domains --region us-west-2 ``` The following shows the example JSON response. This rule group has only `RulesSource` defined, which contains the domain list inspection specifications. ``` { "UpdateToken": "a4648a25-e315-4d17-8553-283c2eb33118", "RuleGroup": { "RulesSource": { "RulesSourceList": { "Targets": [ ".example.com", "www.example.org" ], "TargetTypes": [ "HTTP_HOST", "TLS_SNI" ], "GeneratedRulesType": "DENYLIST" } } }, "RuleGroupResponse": { "RuleGroupArn": "arn:aws:network-firewall:us-west-2:111122223333:stateful-rulegroup/domains", "RuleGroupName": "domains", "RuleGroupId": "f3333333-fb99-11c1-bbe3-1d1caf1d1111", "Type": "STATEFUL", "Capacity": 100, "RuleGroupStatus": "ACTIVE", "Tags": [] } } ``` Variable settings are defined for a rule group in a `RuleVariables` setting. This rule group currently has no `HOME_NET` variable declaration, so we know that `HOME_NET` is set to the default. In our example case, it's `192.0.2.0/24`. To add CIDR ranges to the `HOME_NET` setting, we update the rule group with our variable declaration. The following shows a file named `variables.json` that contains the rule group JSON with the added variables settings: ``` { "RuleVariables": { "IPSets": { "HOME_NET": { "Definition": [ "10.0.0.0/16", "10.1.0.0/16", "192.0.2.0/24" ] } } }, "RulesSource": { "RulesSourceList": { "Targets": [ ".example.com", "www.example.org" ], "TargetTypes": [ "HTTP_HOST", "TLS_SNI" ], "GeneratedRulesType": "DENYLIST" } } } ``` The following command uses the `variables.json` file to update the rule group definition with the correct `HOME_NET` settings: ``` aws network-firewall update-rule-group \ --rule-group-arn arn:aws:network-firewall:us-west-2:111122223333:stateful-rulegroup/domains \ --update-token a4648a25-e315-4d17-8553-283c2eb33118 \ --rule-group file://variables.json \ --region us-west-2 ``` The following shows an example response to the call: ``` { "UpdateToken": "32ebfb82-40a2-4896-b34d-91dada978f67", "RuleGroupResponse": { "RuleGroupArn": "arn:aws:network-firewall:us-west-2:111122223333:stateful-rulegroup/domains", "RuleGroupName": "domains", "RuleGroupId": "f3333333-fb99-11c1-bbe3-1d1caf1d1111", "Type": "STATEFUL", "Capacity": 100, "RuleGroupStatus": "ACTIVE", "Tags": [] } } ``` If we retrieve the `domains` rule group again, we see that the rule group has the added variable definition: ``` aws network-firewall describe-rule-group --type STATEFUL \ --rule-group-name domains --region us-west-2 ``` The response JSON contains the added variable: ``` { "UpdateToken": "42ffac91-20b5-5512-a24c-85cbca797e23", "RuleGroup": { "RuleVariables": { "IPSets": { "HOME_NET": { "Definition": [ "10.0.0.0/16", "10.1.0.0/16", "192.0.2.0/24" ] } } }, "RulesSource": { "RulesSourceList": { "Targets": [ ".example.com", "www.example.org" ], "TargetTypes": [ "HTTP_HOST", "TLS_SNI" ], "GeneratedRulesType": "DENYLIST" } } }, "RuleGroupResponse": { "RuleGroupArn": "arn:aws:network-firewall:us-west-2:111122223333:stateful-rulegroup/domains", "RuleGroupName": "domains", "RuleGroupId": "f3333333-fb99-11c1-bbe3-1d1caf1d1111", "Type": "STATEFUL", "Capacity": 100, "RuleGroupStatus": "ACTIVE", "Tags": [] } } ``` # IP set references in Suricata compatible AWS Network Firewall rule groups IP set referencesNew resource type for IP set references You can now include resource groups in your IP set references.New topic on using IP set references IP set references enable you to reference an IP set resource, such as an Amazon VPC prefix list, in your Suricata compatible stateful rules. You can use an IP set reference with **Suricata compatible rule strings** and with **standard Network Firewall stateful rule groups**. An *IP set reference* is a Network Firewall rule group variable that references a set of IP addresses or CIDR blocks contained in an AWS resource, such as an Amazon Virtual Private Cloud prefix list. IP set references enable you to dynamically use IP addresses or CIDRs from another AWS service in your Suricata compatible rules. When you create, update, or delete the IP sets that you reference in your rules, Network Firewall automatically updates the rules with the changes. For example, if you add five CIDRs to an IP set resource that you're referencing in a rule, then the rule will automatically include the five CIDRs that you added to the resource. Network Firewall currently supports the following AWS resources as IP set references: + **Amazon VPC prefix lists**. For information about referencing Amazon VPC prefix lists in your rule groups, see the following section [Referencing Amazon VPC prefix lists](#rule-groups-referencing-prefix-lists). + **Resource groups**. For information about referencing resource groups in your rule groups, see following section [Referencing resource groups](#rule-groups-referencing-resource-groups). For an example of a rule that uses an IP set reference, see [Stateful rules examples: IP set reference](suricata-examples.md#suricata-example-rule-with-ip-set-reference). For more information about adding IP sets to your Suricata compatible rule groups via the console, see the [Creating a stateful rule group](rule-group-stateful-creating.md) procedure. ## Limits for IP set references The following limits apply to IP set references: + Maximum of five IP set references per rule group. You can use IP set references in addition to IP set variables or port variables in a rule group. Only IP set references count against this limit. + Maximum of 1,000,000 CIDRs - You can use a maximum of 1,000,000 CIDRs in all of the IP set references used in a single firewall. If you exceed this limit, then Network Firewall includes only the first 1,000,000 CIDRs from your referenced IP set resources. Network Firewall calculates CIDRs differently for prefix lists and resource groups: + Prefix lists – Network Firewall takes an aggregated account of the CIDRs in each referenced IP set. + Resource groups – Network Firewall calculates the number of IP addresses associated with all of the resources in the group, such as all of the IP addresses associated with an Amazon EC2 instance, both public and private. ## Referencing Amazon VPC prefix lists Referencing Amazon VPC prefix lists A *prefix list* is a set of one or more CIDR block entries that you can use to configure security groups, routing tables, and transit gateways in Amazon VPC. A reference to a prefix list helps you to simplify the management of the CIDR blocks in your rules. If you frequently use the same CIDRs across multiple rules, you can manage those CIDRs in a single prefix list, instead of repeatedly referencing the same CIDRs in each rule. If you need to remove a CIDR block, you can remove its entry from the prefix list instead of removing the CIDR from every affected rule. For more information about Amazon VPC prefix lists, see [Group CIDR blocks using managed prefix lists ](https://docs.aws.amazon.com/vpc/latest/userguide/managed-prefix-lists.html) in the *Amazon VPC User Guide*. ## Referencing resource groups Referencing resource groups A *tag-based resource group* is a collection of AWS resources whose membership in a resource group is based on tags. Tags are key value metadata that you associated with a resource type, such as an Amazon EC2 instance. Similar to prefix lists, a reference to a resource group helps you to simplify the management of the IP addresses in your rules. If you frequently want to reference the IP addresses of the same set of resources, you can manage those IPs in a single resource group, instead of repeatedly referencing the same IPs in each rule. Network Firewall constantly checks for resources that match the resource group grouping criteria in your account, and then resolves IPs of the matching resources in the rule. If you need to remove a set of IP addresses, you can remove the tagged resource type from the resources group instead of removing the IP from every affected rule. For more information about using resource groups in Network Firewall, see [Using tag-based resource groups in Network Firewall](resource-groups.md). # Geographic IP filtering in Suricata compatible AWS Network Firewall rule groups Geographic IP filteringCountry code filtering in stateful rules You can now use the Suricata `geoip` keyword in stateful rules, to filter for the country codes associated with IP addresses. You can use Geographic IP filtering with **Suricata compatible rule strings** and with **standard Network Firewall stateful rule groups**. This optional filter matches country codes for the IP addresses of network traffic. Suricata supports filtering for source and destination IPs. You can filter on either of these types by itself, by specifying `dst` or `src`. You can filter on the two types together with AND or OR logic, by specifying `both` or `any`. For more information see the Suricata `geoip` keyword documentation at [IP Keywords: geoip](https://docs.suricata.io/en/suricata-7.0.8/rules/header-keywords.html?highlight=geoip#geoip). To use a Geographic IP filter, you provide the `geoip` keyword, the filter type, and the country codes for the countries that you want to filter for, for example `geoip:dst,CN,US;`. For additional examples, see [Stateful rules examples: Geographic IP filter](suricata-examples.md#suricata-example-rule-with-geo-ip-filter). For more information about adding Geographic IP filtering to your Suricata compatible rule groups via the console, see the [Creating a stateful rule group](rule-group-stateful-creating.md) procedure. **IPv4 and IPv6 support** The Network Firewall implementation of Suricata `geoip` provides support for IPv6 and IPv4. This is an expansion of the support provided by Suricata. **MaxMind IP geolocation** Suricata determines the location of requests using MaxMind GeoIP databases. MaxMind reports very high accuracy of their data at the country level, although accuracy varies according to factors such as country and type of IP. For more information about MaxMind, see [MaxMind IP Geolocation](https://support.maxmind.com/hc/en-us/sections/4407519834267-IP-Geolocation). If you think any of the geographic IP data is incorrect, you can submit a correction request to Maxmind at [MaxMind Correct GeoIP Data](https://support.maxmind.com/hc/en-us/articles/4408252036123-GeoIP-Correction). **Country codes** IP geolocation uses the alpha-2 country codes from the International Organization for Standardization (ISO) 3166 standard. + You can search country codes at the ISO website, at [ISO Online Browsing Platform (OBP)](https://www.iso.org/obp/ui#home). + You can also find them listed on Wikipedia, at [ISO 3166-2](https://en.wikipedia.org/wiki/ISO_3166-2). Network Firewall only allows you to save Geographic IP filter rules that have valid country codes. If you configure Geographic IP rules to allow or pass connections to IP addresses in specific countries, we recommend that you set the Default action on your firewall policy to one of our available Drop actions. Geographic IP country mappings are derived from the MaxMind database, and IP-to-country associations can change between database updates. By configuring a default drop action, you ensure that if an IP address is reassigned to a different country and no longer matches your allow rule or any other rules in your firewall policy, the firewall drops the connection. AWS Network Firewall uses the MaxMind GeoIP database to resolve IP addresses to their associated countries. While MaxMind provides industry-standard geolocation data, IP-to-country associations may be inaccurate or change over time due to IP address reassignments, database updates, or other factors. Before you create or troubleshoot Geographic IP rules, verify the country mapping of your target IP addresses by using the [MaxMind IP lookup tool](https://www.maxmind.com/en/geoip-demo). This helps you confirm that the IP addresses you expect to match a given country code are correctly classified in the database and can prevent unexpected rule behavior. However, the lookup tool reflects MaxMind's most current data - AWS Network Firewall's database is updated on a rolling basis, so there may be a brief window where mappings differ. If this is the case, refer to the Workarounds section below for options to override specific IPs. If you observe that an IP address is being incorrectly allowed by a Geographic IP rule due to a country mapping change or database inaccuracy, you can create an explicit deny or reject rule in your rule group that targets the specific IP address. You would need to place this rule with a higher priority than the original rule for it to take precedence. Please see [Managing Evaluation order for Suricata compatible rules in AWS Network Firewall](https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-rule-evaluation-order.html). # URL and Domain Category Filtering in Suricata compatible AWS Network Firewall rule groups URL and Domain Category Filteringurl/domain based filtering in stateful rules You can now use `aws_url_category` and `aws_domain_category` keywords in stateful rules, to filter traffic based on web content categories URL and Domain Category filtering enables you to filter network traffic based on predefined content categories. You can use this feature with **Suricata compatible rule strings** and **standard Network Firewall stateful rule groups**. Network Firewall provides two filtering keywords: + `aws_url_category` - Evaluates complete URLs and domains in HTTP/HTTPS traffic + `aws_domain_category` - Evaluates only domain information from TLS SNI or HTTP host headers To use URL and Domain Category filtering, you provide either the `aws_url_category` or `aws_domain_category` keyword followed by the category you want to filter for, for example `aws_url_category:Malicious;` You can specify multiple categories per rule. For additional examples, see [Stateful rules examples: URL/Domain Category filter](suricata-examples.md#suricata-example-rule-with-url-filter). **How URL and Domain Category filtering works** **aws\$1url\$1category keyword** + Supported protocol in rules: HTTP + Traffic handling: + **For HTTP traffic** - Evaluates complete URLs + **For HTTPS traffic** - Requires TLS inspection to evaluate URLs. Without TLS inspection, HTTPS traffic is treated as encrypted TLS traffic and cannot be evaluated + Performs evaluation in the following order: + Complete URL path evaluation (up to 30 recursive path lookups) + If no match is found, falls back to domain-level evaluation (up to 10 recursive subdomain lookups) + Matches against: + URI field from HTTP request headers (requires TLS inspection for HTTPS traffic) + Host field from HTTP request headers **aws\$1domain\$1category keyword** + Supported protocols in rules: TLS, HTTP + Traffic handling: + **For HTTP traffic** - Evaluates domain from Host field + **For TLS traffic** - Evaluates domain from SNI field + No TLS inspection required + Performs domain-level evaluation: + Evaluates only domain-level information (up to 10 recursive subdomain lookups) + Matches against: + Server Name Indication (SNI) field from TLS handshake + Host field from HTTP request headers **Supported Categories** ``` "Abortion", "Adult and Mature Content", "Artificial Intelligence and Machine Learning", "Arts and Culture", "Business and Economy", "Career and Job Search", "Child Abuse", "Command and Control", "Criminal and Illegal Activities", "Cryptocurrency", "Dating", "Education", "Email", "Entertainment", "Family and Parenting", "Fashion", "Financial Services", "Food and Dining", "For Kids", "Gambling", "Government and Legal", "Hacking", "Health", "Hobbies and Interest", "Home and Garden", "Lifestyle", "Malicious", "Malware", "Marijuana", "Military", "News", "Online Ads", "Parked Domains", "Pets", "Phishing", "Private IP Address", "Proxy Avoidance", "Real Estate", "Redirect", "Religion", "Search Engines and Portals", "Science", "Shopping", "Social Networking", "Spam", "Sports and Recreation", "Technology and Internet", "Translation", "Travel", "Vehicles", "Violence and Hate Speech" ``` **Considerations** + [TLS inspection](https://docs.aws.amazon.com/network-firewall/latest/developerguide/tls-inspection-configurations.html) must be enabled on your firewall to perform URL category filtering on HTTPS traffic + Without TLS inspection, only domain-level filtering is possible for encrypted traffic + A single URL may map to multiple categories + Category database is automatically maintained and updated + You can specify multiple categories in a single rule + You cannot combine URL/Domain category filtering keywords (`aws_url_category, aws_domain_category`) with geographic IP filtering (`geoip`) in the same rule. You must create separate rules if you want to filter traffic using both geographic IP filter and URL /Domain Category filter. + Using URL/Domain category filtering may increase traffic latency due to the additional category lookups performed for each connection matching the rule protocol and IP specifications.