Traffic inspection on AWS Outposts rack with FortiGate Next-Generation Firewall

Maintaining data security and regulatory compliance within your on-premises infrastructure is crucial, and network traffic monitoring on AWS Outposts plays a vital role in achieving this goal. By implementing network traffic inspection capabilities, you gain comprehensive visibility into the data flow occurring within your Outposts environment. You can proactively identify and mitigate potential threats like SSL spoofing and brute-force password attacks.

AWS Partner Network (APN) solutions deployed on Outposts can be used to harness specialized capabilities tailored to analyze network traffic patterns and detect and mitigate threats. These solutions also facilitate adherence to industry-specific regulations and standards. Advanced capabilities include deep packet inspection, intrusion detection and prevention systems, application-level firewalling, and sophisticated threat detection mechanisms.

Prerequisites

• Deploy an Outpost on premises
• Create four VPCs: exposed, firewall, IT, and operational technologies (OT)
• Create private subnets in each of the four VPCs where elastic network interfaces and instances can be created
• Create elastic network interfaces in each of the four private subnets for attachment to the firewall instance (make a note of the network interface IDs)
• Disable source and destination tracking on each network interface created for attaching to the firewall instance
• (Optional) Share the subnets and network interfaces with the firewall account using AWS Resource Access Manager (AWS RAM)
• Associate the exposed VPC to the local gateway

Solution overview

This post presents an example of an architectural blueprint that illustrates the deployment and the testing of the Fortinet FortiGate Next-Generation Firewall (NGFW) virtual appliance on Outposts available in AWS Marketplace. The Fortinet NGFW enables inline traffic inspection for data transfers between your on-premises environment and workloads on Outposts. It also provides security services between Outposts instances in different virtual private clouds (VPCs).

The following diagram shows the example traffic inspection architecture. For a detailed explanation, refer to the architecture section of Implementing network traffic inspection on AWS Outposts rack.

Figure 1: Example traffic inspection architecture

To set up the example used in this post, follow all the steps described in the Implementation on AWS Outposts rack section of Implementing network traffic inspection on AWS Outposts rack.

In that post, the example was deployed on Outposts with a generic Linux instance that acted as a firewall with routing capabilities. However, in this post, it uses an Amazon Elastic Compute Cloud (Amazon EC2) instance using the Fortinet FortiGate Next-Generation Firewall (NGFW) Amazon Machine Image (AMI) available in AWS Marketplace.

For instructions on how to launch an EC2 instance with the FortiGate NGFW AMI, refer to Subscribing to the FortiGate.

After launching the firewall instance and performing all other steps of the Implementation on AWS Outposts rack section, you must configure the additional interfaces (port2, port3, and port4 in figure 1) through the FortiGate console:

1. Go to Network and then the Interfaces The additional interfaces must be configured to obtain IP through Dynamic Host Configuration Protocol (DHCP). By default, only port1 is configured to obtain the address through DHCP. This means that port1 is also designed by default to be the interface that routes traffic to the internet. For port1, ensure the Retrieve default gateway from server toggle is switched on. (figure 3)

Figure 2: Network interfaces

2. On the Physical Interface screen, select port2. Choose Edit.
3. Under Address, select DHCP. Choose OK. (In our configuration, port2 is also designed to route internet traffic. Ensure the Retrieve default gateway from server setting is turned on.)

Figure 3: Edit Network interface

4. Repeat step 2 for port3 and port4, and under Address, select DHCP. Choose OK. Ensure the Retrieve default gateway from server setting is turned off.
5. After reloading the page, you will be able to observe the same IP that was assigned at the VPC level (the same addresses showed in figure 1). The following screenshot shows the IPs for the network interfaces.

Figure 4: Network interface IPs

6. To double-check the routing table of the firewall instance, connect into the instance by using Secure Shell (SSH). Show the route table with the command get router info routing-table all.

Figure 5: Firewall routing table

Test scenarios

In this section, we demonstrate two types of tests. In the first one, the NGFW instance will allow or block straightforward types of inter-VPC traffic such as HTTPS and Internet Control Message Protocol (ICMP) traffic. In the second test, advanced capabilities such as an intrusion prevention system (IPS) are demonstrated.

Scenario Setup – Configure a standard firewall policy

To start, we will use the below steps to configure a standard policy for a three-tier web application. This policy will allow HTTPS and MySQL protocol from the OT VPC to the IT VPC.

1. On the FortiGate console, go to Policy & Objects and then the Firewall Policy
2. Choose Create New.
3. Enter a Name for the policy (refer to 1 in figure 6).
4. Select the appropriate ports for Incoming Interface and Outgoing Interface (refer to 2 and 3 in figure 6). In this example, the OT VPC communicates with the firewall through port3, and the IT VPC communicates through port4. Check the correct interface from the Network > Interfaces section of the FortiGate console.
5. For Source and Destination (refer to 4 and 5 in figure 6), select all so the policy can be applied to all traffic from the OT VPC to the IT VPC, regardless of the specific source or destination address.
6. For Service (refer to 6 in figure 6), select HTTPS and MYSQL, which are the only protocols allowed from the OT VPC to the IT VPC.
7. Turn off NAT (refer to 7 in figure 6). You don’t need to perform network address translation on the traffic, so the original source IP address will be preserved when delivered from the source to the destination.
8. No advanced features are turned on in the Security Profiles (refer to 8 in figure 6).
9. To make sure the traffic flows through the firewall as expected, select All Sessions in the Log Allowed Traffic option (refer to 9 in figure 6).
10. Choose OK to create the policy.

Figure 6: Firewall policy example

Scenario 1 – Test the standard policy

To test the newly created policy, use two EC2 instances created in the OT VPC (source IP 10.242.0.108) and the IT VPC (destination IP 10.244.0.175).

Since the security policy doesn’t allow the ICMP protocol, attempting to ping from the OT instance to the IT instance fails. However, because HTTPS is allowed, opening a connection on port 443 succeeds, as shown in figure 7.

Figure 7: ICMP and HTTPS test

You can confirm that the policy is allowing traffic by checking the Log & Report section of the firewall console.

Figure 8: HTTPS firewall logs

Scenario 2 – Configure an advanced policy with IPS and SSL inspection

One of the benefits of using solutions such as the Fortinet NGFW is that you can use an IPS (Intrusion Prevention System). Although you can natively block ICMP traffic with Security Groups in a VPC, you need a third-party solution on AWS Outposts to have IPS functionality.

In this section, we demonstrate how to use policies to protect against advanced threats such as a brute-force MySQL authentication. The goal of the following section is to enable IPS capabilities to block high-severity threats.

1. On the FortiGate console, go to the Firewall Policy section and select the OTVPC-to-ITVPC Choose Edit.
2. To turn on IPS inspection, under Security Profiles, select the radio button and choose a profile, as shown in figure 9. In the following example, the pre-defined high_security profile is selected, which provides protection against high priority risks.

Figure 9: Advanced firewall policy example

Scenario 2 – Test the advanced policy

To test the IPS capabilities, we used the CVE-2012-2122 exploit, which is a brute-force authentication attack against a MySQL server. By using this vulnerability, an attacker is able to bypass authentication by repeatedly authenticating on the remote MySQL server with the same incorrect password. The attack is simulated by the Python script referenced in the hyperlinked Common Vulnerabilities and Exposures (CVE) record. The following screenshot shows the script.

Figure 10: Example script used for MySQL brute force attack

Running the script in figure 10, we observed that after approximately 40 login attempts in a few seconds, the client couldn’t open any new TCP connections towards the server, as shown in figure 11.

Figure 11: Login attempts

The high_security profile that was selected in the policy configuration offers protection against CVE-2012-2122 that we are trying to exploit via this test. As soon as the firewall detects the attack, it will automatically take the action to stop any further login attempt.

You can confirm that the firewall has detected and blocked the attack by checking the security events on the FortiGate console. Go to Log & Report and then the Security Events section. The following screenshot shows that the firewall has detected a MySQL.Login.Brute.Force event and dropped the traffic.

Figure 12: Security events section

Select the event to access the Logs section, which shows the source IP, the attack type, and the dropped action.

Figure 13: Firewall logs for the security event

Clean up

Please follow the below instructions to clean up after testing:

• Terminate the FortiGate EC2 instance
• Terminate the EC2 test instances
• Remove the “Exposed VPC” from the Local Gateway Route Table
• Delete all VPCs

Conclusion

This post explored a robust solution for implementing comprehensive traffic inspection in hybrid and multi-VPC environments on AWS Outposts using the Fortinet Next-Generation Firewall solution available in AWS Marketplace.

By using third-party solutions available in AWS Marketplace, customers can protect their workloads from various threats through a variety of features. This can range from straightforward mechanisms such as port-based access control lists (ACLs) to advanced solutions such as intrusion prevention systems (IPS) detecting brute force attacks.

To learn more about security at AWS, visit the AWS Cloud Security page and Security in AWS Outposts.

About Authors