AWS Reference Architecture - CloudGen Firewall Auto Scaling Cluster

Protecting highly dynamic AWS resources with a static firewall setup is neither efficient nor economical. A CloudGen Firewall Auto Scaling Cluster scales with demand, thereby creating a cost-effective, robust solution for securing and connecting to your cloud resources. The firewall cluster can be deployed either to integrate with existing resources in an AWS region, or as part of an auto scaling application. Both options offer an integrated Barracuda Web Application Firewall (WAF) as a second security tier. The firewall cluster integrates tightly with AWS services and APIs. Configuration changes are synchronized securely over the AWS backend, with all instances sharing the same configuration. The admin can configure the changes like a single firewall instance. The firewall cluster is highly available and scalable over multiple AWS Availability Zones, without any single point of failure such as additional management or worker node instances. The firewall cluster uses the PAYG image of the Barracuda CloudGen Firewall in the AWS Marketplace. This allows you to quickly deploy without the need for long-term licensing commitments. CloudGen Firewall clusters cannot be managed by a Firewall Control Center.

Use Cases for a CloudGen Firewall Auto Scaling Cluster

Secure Remote Access – Client-to-site VPN, CudaLaunch, and SSL VPN using the TINA VPN protocol.
Edge Firewall – Scan for malicious traffic using the built-in IPS and handle access to resources via access rules.

AWS Architectures for CloudGen Firewall Auto Scaling Clusters

Since there are no external dependencies, the CloudGen Firewall cluster can either be used as a drop-in solution to protect your existing applications in the same AWS region, or it can be included as part of the architecture of your application.

Transit VPC with VPC Peering

The firewall cluster is used in a Transit VPC configuration. The firewall VPC acts as a hub securing all traffic in and out of the peered VPCs. Two peered VPCs must be in the same AWS region, but can be in different AWS accounts. Transitive peering is not possible; therefore, resources in two VPCs both peered with the Transit VPC cannot communicate with each other. Incoming traffic is handled via access rules allowing access to the backend resources based on the access rule matching criteria, such as source, user, or time. Since the VPC for the firewall cluster is separated from the VPCs containing the applications, rapid iteration of the applications is possible without requiring changes to the firewall cluster. For example, in a typical scenario with production, engineering, and development VPCs, granular access rules allow the firewall admin to separate users based on their role:

Traffic to production VPCs is secured by IPS and, optionally, forwarded to a Web Application Firewall cluster.
QA and developers log in via client-to-site VPN. The firewall uses the user information to allow access only to their respective VPCs.
Admins are in a special group, allowing them backend access to production and QA VPCs.

Transit VPC with VPC Peering and Barracuda Web Application Firewall Auto Scaling Cluster

A variation of the transit VPC includes an additional Web Application Firewall cluster behind the CloudGen Firewall cluster. The Barracuda Web Application Firewall and CloudGen Firewall F can work in tandem to block IP addresses from which malicious activity was detected. Whereas the WAF is very good at detecting application layer attacks, the CloudGen Firewall is more efficient on the network layer. Connections blocked by the firewall IPS are never forwarded to the WAF, thereby freeing resources that would otherwise have to be used to block known-bad connections.

Integration into AWS Architecture

You can integrate the firewall cluster into your existing architecture. Use the default CloudFormation template as reference. To be able to reuse the configuration, configure the CloudGen Firewall cluster one time via Barracuda Firewall Admin, and then replicate the S3 bucket to reuse the configuration.

Deploying a CloudGen Firewall Auto Scaling Cluster

The firewall cluster must be deployed via CloudFormation template. The template deploys a VPC with public and private subnets in two Availability Zones. In the private subnets, the firewall cluster is deployed. In the public subnets, the Elastic Load Balancer (ELB) and two NAT gateways are deployed (one for each Availability Zone). The NAT gateways are required for the firewalls to be able to access the AWS backend. APIs are required to enable the secure configuration sync over the AWS backend.

Create an IAM role for the firewall cluster. For step-by-step instructions, see How to Create an IAM Role for a CloudGen Firewall in AWS.
Download the NGF_Autoscaling.json template and parameter file from the Barracuda Network GitHub account: https://github.com/barracudanetworks/ngf-aws-templates/tree/master/ASG.
Accept the Software Terms for the Barracuda CloudGen Firewall PAYG image in the AWS Marketplace.
Create a parameter template file containing your parameters values.
Deploy the autoscale.json CloudFormation template via AWS CLI or AWS console.
aws cloudformation create-stack --stack-name "YOUR_STACK_NAME" --template-body YOUR_S3_BUCKET/NGF_Autoscaling.json --parameter YOUR_S3_BUCKET/NGF_Autoscaling_parameters.json

During deployment, the following resources are created by the template:

VPC with private and public subnets in two Availability Zones.
Two ELBs: one for management connections, the other for VPN and SSL VPN services.
One S3 bucket.
Automatically created SNS and SQS queues.
Two NAT gateways.
A Launch Configuration and Auto Scaling group for the firewall. The Barracuda CloudGen Firewall PAYG image must be used.
Scaling policies using the number of client-to-site VPN tunnels.

After stack creation is complete, the FQDN of the ELB are listed in the Output tab.

For step-by-steps instructions, see How to Deploy a CloudGen Firewall Auto Scaling Cluster in AWS.

Remote Access

Remote Access features offer remote users secure access to their organization's cloud applications and resources from virtually any device. Depending on the type of access users require, they can choose between the full client-to-site VPN or the SSL VPN web portal.

Client-to-Site VPN

The client-to-site VPN uses the TINA VPN protocol on TCP port 691 to connect to the firewall cluster. TINA is designed to overcome limitations imposed by the IPsec protocol and offers immunity to NAT devices or proxies, heartbeat monitoring, and fast failover support. VPN clients can be authenticated through client certificates, external and internal authentication schemes, or a combination thereof. Supported VPN clients are:

Barracuda VPN / NAC Client for Windows, macOS, Linux, and OpenBSD.
CudaLaunch for Windows, macOS, iOS, and Android version 2.3.0 or higher.

On the CloudGen Firewall Auto Scaling Cluster, configure the VPN service for client-to-site connections by adding one or more VPN group policies. Incoming client-to-site connections are matched to a VPN group policy based on the group policy condition. The first matching VPN group policy is chosen. VPN group policy conditions allow you to define the following criteria:

Group patterns from external authentication schemes
X.509 certificate conditions
VPN clients
Source IP address or network for the VPN clients

For step-by-step instructions, see How to Configure a Client-to-Site VPN Group Policy for an CloudGen Firewall Auto Scaling Cluster in AWS.

SSL VPN and CudaLaunch

The SSL VPN service provides seamless integration without having to install a client app. For a richer level of remote access, CudaLaunch works with the SSL VPN service to provide more advanced SSL VPN features such as SSL tunneling or native app support. The number of simultaneous users using the SSL VPN is limited only by the performance and number of firewall instances in the Auto Scaling group. Since the SSL VPN service is not designed to share session information between the members of the Auto Scaling group, the ELB must be configured to use sticky sessions and SSL offloading to ensure that the individual client will always be redirected to the same firewall instance. SSL VPN resources can be accessed by the following clients:

CudaLaunch
SSL VPN web interface – All modern browsers.

For step-by-step instruction, see How to Configure the SSL VPN Services for AWS Auto Scaling Clusters.

Firewall and IPS

The firewall cluster secures incoming and outgoing traffic from your AWS resources. This can be traffic from AWS instances in peered VPCs or instances in the private networks of the VPC. If enabled on the access rule matching the traffic, the IPS engine on the firewall continuously compares the packet stream with the internal signatures database for malicious code patterns. If malicious packets are identified, traffic is either reported or dropped, depending on the configuration of the IPS. To ensure that the latest patterns are used, the IPS patterns are updated automatically from the Barracuda Networks download servers.

When used in combination with a Barracuda Web Application Firewall cluster, the IPS and access rules block network layer attacks, saving processing power on the WAF for layer 7 attacks. For traffic to be able to flow through the firewall cluster and back, all access rules must use both source and destination IP address translation (NAT). This ensures that traffic will go back over the same firewall. The CloudGen Firewall Auto Scaling Cluster cannot be used as the default gateways for your AWS resources.

Configuration and Monitoring

Barracuda Firewall Admin is a stand-alone, multi-administrator Microsoft Windows application used to administer CloudGen Firewalls. Managing the configuration of the firewall cluster is very similar to managing a single firewall. Connect to the cluster through the ELB with a listener on TCP 807. This instance now transparently redirects the connections to other instances in the cluster as needed. Information on some tabs, such as the CONFIGURATION and VPN tabs, are aggregated by combining the data from all firewalls in the cluster. The FIREWALL > History page also displays connection data from all firewalls in the cluster. All other tabs and configuration elements display only the information of the firewall instance Firewall Admin is currently connected to.

Aggregated tabs – All pages in the CONFIGURATION tab.
Aggregated pages – VPN > Client-to-Site , VPN > Site-to-Site and FIREWALL > History.
Aggregated dashboard elements – Updates element on the General dashboard.

On pages that display aggregated data from all firewall instances in the cluster, use the Instance ID column to filter or group the information by instance.

Login and Default Password

Connect to the firewall cluster via Firewall Admin using the FQDN of the ELB with a listener on TCP 807. The default password is the instance ID of the first instance in the Auto Scaling group. Go to the Instance tab of the Auto Scaling group and locate the instance that is protected from scale in to identify the first instance.

IP Address /Name – Enter the DNS name of the management ELB in front of the firewall cluster.
User – Enter root.
Password – The default password is the instance ID of the first instance.

After logging in the first time, you are prompted to change your password.

Log Streaming to AWS CloudWatch

Log files stored on the firewall instances themselves are ephemeral. As soon as an instance is terminated, the log files are deleted with it. To keep the log files for later analysis, troubleshooting, or regulatory reasons, use syslog streaming on the firewalls to send them to AWS CloudWatch. There, the logs can be placed in groups, filtered, or processed further.

For step-by-step instructions, see How to Configure Log Streaming to AWS CloudWatch.