Lab 4 - Threat Hunting with AWS Network Firewall

Resources required for this lab are only available in Distributed Deployment Model Setup. Resource names may vary depending on the CloudFormation stack name you provided.

Are you up for a challenge? This lab will show you how to quickly use AWS Network Firewall to hunt for suspicious network activity that may indicate a compromise of your infrastructure. In this lab you will be looking for non-TLS TCP traffic that is traversing over port 443 on your network, this type of network traffic is uncommon and should be investigated. Take this extra challenge to see if you can determine what is going and then how you can block this behavior.

To generate some interesting traffic for you to investigate, we have deployed compute resources which are protected by AWS Network Firewall along with a malicious host.


1. Create a Firewall Policy to detect non-TLS traffic over TLS ports

First, you need to add a new Stateful Rule to Firewall Policy. Navigate to AWS ConsoleVPCAWS Network FirewallNetwork Firewall rule groups. In the upper right corner click on “Create Network Firewall rule group”.

lab4

Next, create a new stateful Suricata rule with the following parameters:

  • Name: Suricata-detect-non-TLS-over-TLS-Ports
  • Description: This rule will detect non-TLS traffic over ports 443
  • Capacity: 10 (each Suricata rule counts as 1 capacity unit, we’ll leave extra capacity for you to experiment later)
  • Select the radio button: Suricata compatible IPS rules
  • Copy and paste the following Suricata rule:
alert tcp any any <> any 443 (msg:"SURICATA Port 443 but not TLS"; flow:to_server,established; app-layer-protocol:!tls; sid:2271003; rev:1;)

This rule will alert on TCP traffic from any interface in either direction <> over port 443 that is not !tls protocol. For more Suricata rule examples click here.

lab4


2. Add the newly created firewall rule to the existing firewall policy

In next step, you will add your newly created rule to the Firewall policy. Navigate to AWS ConsoleVPCAWS Network FirewallFirewall policies.

If you have followed the previous labs you should have a policy named firewall-policy-anfw-distributed-xxxx, click on that policy to begin editing it.

lab4

Next click on the “Add rule groups” option in the lower right, then click on “Add statefule rule groups to the firewall policy”. lab4

Next select the newly created Suricata rule and click “Add stateful rule group”. lab4

The Stateful rule groups should now look like this: lab4


3. Time to investigate

In next step, you will check the activity of your firewall. Navigate to AWS ConsoleVPCAWS Network FirewallFirewall. Now let’s check and see if traffic is flowing through the Network Firewall by click on the “Monitoring” tab to see activity, (it make take a few minutes to appear, hit the graph refresh button in the lower right until you see some traffic). lab4

Next, click on the “Firewall details” tab and note the CloudWatch log group location where the alerts are going. lab4

Next, navigate to the CloudWatch page: AWS ConsoleCloudWatchLog groups then click on /anfw-distributed/anfw/alert to view the logs generated. lab4

It may take 5-10 minutes before the logs show up in CloudWatch, when it does you may see multiple log streams, go into several of them and investigate what the alerts are about. Do you see anything suspicious? What protocol was actually in use? lab4

Click **here** to reveal a hint.
HINT - What does the 'alert' : 'signature' say that might be worth investigating? Do you see anything else interesting?

lab4


You discovered some instances are communicating non-TLS traffic over port 443, now what changes could you make to block that activity? Go ahead and make those changes and observe if they were effective.


Click **here** to reveal the solution. Look at the Suricata rule you created to detect non-TLS traffic, what parameter change would *drop* the traffic?
change:
alert tcp any any <> any 443 (msg:"SURICATA Port 443 but not TLS"; flow:to_server,established; app-layer-protocol:!tls; sid:2271003; rev:1;)

to: drop tcp any any <> any 443 (msg:“SURICATA Port 443 but not TLS”; flow:to_server,established; app-layer-protocol:!tls; sid:2271003; rev:1;)


After you changed ‘alert’ to ‘drop’ was the communication interrupted? Go check the latest entries in CloudWatch logs.

Click **here** to reveal a hint.
HINT - Check CloudWatch logs for an entry like this:

lab4


4. Summary

In this lab you saw that the AWS Network Firewall is an effective service for blocking unwanted network activity. Additionally, because of the integration of Suricata rules you have incredible flexibility and control over your AWS VPC network. Please note: It is important to test your rules, some protocols behave differently depending on the ‘flow’ parameter, such as flow:to_server vs. flow:established, read more about that topic here.

Other suggestions:

Other Suricata rule resources:


That concludes this lab on how to use Suricata rules and the AWS Network Firewall to monitor and block suspicious activity.

Don’t forget the final step to clean up before finishing the workshop.