This website post is Part 2 of Hands-on walkthrough of the AWS Network Firewall flexible rules engine – Part 1 . To recap, AWS Network Firewall is really a managed service that provides a flexible rules engine that provides you the capability to write firewall rules for granular policy enforcement. In Part 1 , we shared how exactly to write a rule and the way the rule engine processes rules differently based on whether you’re performing stateless or stateful inspection utilizing the action order method.

In this website, we concentrate on how stateful rules are evaluated utilizing a added feature-the strict &lt recently;em>rule order method. You’re distributed by this feature the capability to set a number of default actions. We demonstrate ways to use this feature to generate or update your rule groups and share scenarios where this feature can be handy.

Furthermore, after scanning this post, you’ll have the ability to deploy an automated serverless solution that retrieves the most recent Suricata-specific rules from the city, such as for example from Proofpoint’s Emerging Threats OPEN ruleset. By deploying such solutions into your Amazon Web Services (AWS) environment, it is possible to seamlessly improve your overall security posture because the solutions fetch the most recent group of intrusion detection system (IDS) rules from Proofpoint (formerly Emerging Threats) and with them as &lt optionally;a href=”https://en.wikipedia.org/wiki/Intrusion_detection_system” target=”_blank” rel=”noopener noreferrer”>intrusion prevention system (IPS) keeping the rule groups updated on your own Network Firewall thereby. You can choose the refresh interval to update these rulesets-the default refresh interval is 6 hours. You can even convert the group of rule groups to intrusion prevention system (IPS) mode. Finally, you have granular visibility of the many categories of rules for the Network Firewall on the AWS Management Console.

So how exactly does Network Firewall evaluate your stateful rule group?

You can find two techniques Network Firewall can evaluate your stateful rule groups: the action ordering method or the strict ordering method. The settings of one’s rule groups must match the settings of the firewall policy they participate in.

With the action order evaluation way for stateless inspection, all individual packets in a flow are evaluated against each rule in the policy. The guidelines are processed to be able in line with the priority assigned in their mind with lowest numbered rules evaluated first. For stateful inspection utilizing the action order evaluation method, the rule engine evaluates in line with the order of these action setting with pass rules first processed, &lt then;span>drop, then alert. The engine stops processing rules whenever a match is found because of it. The firewall also takes under consideration the order that the guidelines come in the rule group, and the priority assigned to the rule, if any. Part 1 provides additional information on action order evaluation.

If your firewall policy is established to utilize strict ordering, Network Firewall now gives you the option to create a strict rule group order for stateful rule groups manually. By using this optional setting, the rule groups are evaluated to be able of priority, beginning with the cheapest numbered rule, and the guidelines in each rule group are processed in the order where they’re defined. It is possible to select which of the &lt also;a href=”https://docs.aws.amazon.com/network-firewall/latest/developerguide/suricata-rule-evaluation-order.html” target=”_blank” rel=”noopener noreferrer”>default actions-drop all, drop established, alert all, or alert established-Network Firewall shall take when following strict rule ordering.

A person scenario where strict rule order is beneficial

Configuring rule groups by action order is suitable for IDS use cases, but is definitely an obstacle for use cases where you deploy firewalls that follow security best practice, that is to permit only what’s required and deny the rest (default deny). You can’t accomplish that best practice utilizing the default action order behavior. However, with strict order functionality, it is possible to develop a firewall policy which allows prioritization of stateful rules, or that may run 5-tuple and Suricata rules simultaneously. Strict rule order lets you have a block of fine-grain rules with specific actions at the start accompanied by a coarse group of rules with specific actions and lastly a default drop action. A good example is shown in Figure 1 that follows.

Figure 1 implies that you can find two different default drop actions you could choose:
drop established and
drop all. In the event that you choose
drop established, Network Firewall drops only the packets which are in established connections. This enables the layer 3 and 4 connection establishment packets which are necessary for the upper-layer connections to be established, while dropping the packets for connections which are established already. This allows application-layer
pass rules to be written in a default-deny setup with no need to create additional rules to permit the lower-layer handshaking elements of the underlying protocols.

The drop all action drops all packets. In this scenario, you will need additional rules to permit lower-level handshakes for protocols to achieve success explicitly. Evaluation order for stateful rule groups provides information on how Network Firewall evaluates the various actions. To be able to set the excess environment variables which are shown in the snippet, follow the instructions outlined in Types of stateful rules for Network Firewall and the Suricata rule variables.

A good example walkthrough to create a Network Firewall policy with a stateful rule group with strict rule order and default drop action

In this section, you’ll begin by developing a firewall policy with strict rule order. From there, you’ll build onto it with the addition of a stateful rule group with strict rule order and modifying the priority order of the guidelines inside a stateful rule group.

Step one 1: Develop a firewall policy with strict rule order

It is possible to configure the default actions on policies using strict rule order, which really is a property that may only be set at creation time as described below.

1. Get on the console and choose the AWS Region where you have Network Firewall.
2. Select VPC service on the search bar.
3. On the left pane, beneath the Network Firewall section, select Firewall policies.
4. Choose Create Firewall policy. In Describe firewall policy, enter a proper name and (optional) description. Choose Next.
5. In the Add rule groups section.
   1. Choose the Stateless default actions:
      1. Under Choose how exactly to treat fragmented packets choose among the options.
      2. Choose among the actions for stateless default actions.
   2. Under Stateful rule default and order action
      1. Under Rule order choose Strict.
      2. Under Default actions pick the default actions for strict rule order. It is possible to select one drop action and something or both of the alert actions from the list.
6. Next, add an optional tag (for instance, for Key enter Name, and for Value enter Firewall-Policy-Non-Production). Review and choose Create to generate the firewall policy.

Step two 2: Develop a stateful rule group with strict rule order

1. Get on the console and choose the AWS Region where you have Network Firewall.
2. Select VPC service on the search bar.
3. On the left pane, beneath the Network Firewall section, select Network Firewall rule groups.
4. In the guts pane, select Create Network Firewall rule group at the top right.
   1. In the rule group type, select Stateful rule group.
   2. Enter a true name, description, and capacity.
   3. In the stateful rule group options select either 5-tuple or Suricata compatible IPS rules. These allow rule order to be strict.
   4. In the Stateful rule order, choose Strict.
   5. In the Add rule section, add the stateful rules that you want. Detailed instructions on developing a rule are available at Developing a stateful rule group.
   6. Finally, Select Create stateful rule group.

Step three 3: Add the stateful rule group with strict rule order to a Network Firewall policy

1. Get on the console and choose the AWS Region where you have Network Firewall.
2. Select VPC service on the search bar.
3. On the left pane, beneath the Network Firewall section, select Firewall policies.
4. Find the network firewall policy you created in step one 1.
5. In the guts pane, in the Stateful rule groups section, select Add rule group.
6. Choose the stateful rule group you created in step two 2. Next, choose Add stateful rule group. That is explained at length in Updating a firewall policy.

Step 4: Modify the priority of existing rules in a stateful rule group

1. Get on the console and choose the AWS Region where you have Network Firewall.
2. Select VPC service on the search bar.
3. On the left pane, beneath the Network Firewall section, choose Network Firewall rule groups.
4. Choose the rule group that you would like to edit the priority of the guidelines.
5. Choose the Edit rules tab. Choose the rule you intend to change the priority of and choose the Move up and Move down buttons to reorder the rule. That is shown in Figure 2.

Note:

• Rule order could be set to strict order only once network firewall rule or policies groups are manufactured. The rule order can’t be changed to strict order evaluation on existing objects.
• It is possible to only associate strict-order rule groups with strict-order policies, and default-order rule groups with default-order policies. If you make an effort to associate an incompatible rule group, you shall get yourself a validation exception.
• Today, creating domain list-type rule groups using strict order isn’t supported. So, you won’t have the ability to associate domain lists with strict order policies. However, 5-tuple and Suricata compatible rules are supported.

Automated serverless treatment for retrieve Suricata rules

To greatly help simplify and keep maintaining your more complex Network Firewall rules, let’s look at an automated serverless solution. An &lt can be used by this solution;a href=”http://aws.amazon.com/cloudwatch” target=”_blank” rel=”noopener noreferrer”>Amazon CloudWatch Events rule that’s operate on a schedule. The rule invokes an AWS Lambda function that fetches the most recent Suricata rules from Proofpoint’s Emerging Threats OPEN ruleset and extracts them to an Amazon Simple Storage Service (Amazon S3) bucket. After the files lands in the S3 bucket another Lambda function is invoked that parses the Suricata rules and creates rule groups which are appropriate for Network Firewall. That is shown in Figure 3 that follows. This solution originated being an AWS Serverless Application Model (AWS SAM) package to create it simpler to deploy. AWS SAM can be an open-source framework which you can use to create serverless applications on AWS. The deployment instructions because of this solution are available in this code repository on GitHub.

Multiple rule groups are manufactured in line with the Suricata IDS categories. This solution lets you selectively change certain rule groups to IPS mode as required by your use case. It achieves this by modifying the default action from alert to drop in the ruleset. The modified stateful rule group could be associated to the active Network Firewall firewall policy. The quota for rule groups may need to be risen to incorporate all categories from Proofpoint’s Emerging Threats OPEN ruleset to meet up your security requirements. A good example screenshot of varied IPS types of rule groups developed by the answer is shown in Figure 4. Establishing rule groups by categories may be the preferred solution to define an IPS rule, as the underlying signatures have already been grouped and maintained by Proofpoint already.

Figure 4: Rule groups developed by the solution predicated on Suricata IPS categories

The answer provides a solution to use logs in CloudWatch to troubleshoot the Suricata rulesets that weren’t successfully transformed into Network Firewall rule groups.

The ultimate rulesets and discarded rules are stored within an S3 bucket for further analysis. That is shown in Figure 5.

Figure 5: Amazon S3 folder structure for storing final applied and discarded rulesets

Conclusion

AWS Network Firewall enables you to inspect traffic at scale in a number of use cases. AWS handles the heavy lifting of deploying the resources, patch management, and ensuring performance at scale which means that your security teams can focus less on operational burdens and much more on strategic initiatives. In this article, we covered an example Network Firewall configuration with strict rule default and order drop. We showed you the way the rule engine evaluates stateful rule groups with strict rule default and order drop. We provided an &lt then;a href=”https://github.com/aws-samples/aws-network-firewall-rulegroups-with-proofpoints-emerging-threats-open-ruleset” target=”_blank” rel=”noopener noreferrer”>automated serverless solution from Proofpoint’s Emerging Threats OPEN ruleset that may help you in establishing set up a baseline for the rule groups. Hopefully this post is effective and we anticipate hearing about how you utilize these latest features which are being put into Network Firewall.