The ThreatX WAF sensor is a Python-based sensor that supports the Google Cloud Platform (GCP).
This guide provides an overview of the deployment process. Contact the ThreatX Security Operations Center (SOC) to request the sensor Python module and supporting files. The module includes a readme with the deployment procedure.
Sensor for GCP Deployment Overview
ThreatX Web Application Firewall (WAF) sensors can be efficiently deployed in GCP environments. The sensor can be implemented as a single instance or in a multiple-instance High Available (HA) configuration.
A scaled ThreatX image deployment within GCP creates a “Load Balancer sandwich” consisting of the ingress GCP Network Load Balancer, the sensors deployed within autoscaling target groups, and the egress (to backend) load balancer or gateway depending on your specific origin architecture.
In an HA configuration, you deploy the sensor image behind a GCP Network Load Balancer. The Network Load Balancer allows for architectures in which the client’s TLS session terminates at the sensor, which makes the client’s session information available to the sensor. This configuration allows TLS client fingerprinting.
To facilitate HA deployment in GCP, ThreatX provides a .yml deployment template and associated python files. You can utilize the template through the Google SDK command line (gcloud). The template framework implements deployment to a greenfield VPC. The deployment template parameters are customizable, which includes the GCP network zones and ThreatX target group parameters.
There are several architectural components deployed with default template parameters. These resources are described in the following sections.
Network Load Balancer
Two Google Network Load Balancers (NLBs) provide ingress to defined target groups of sensors. One NLB is available in each respective zone and utilizes (public internet-facing) permanent IPs created by the deployment stack. The following figure shows the NLBs with TCP listeners.
The NLB can preserve the client IP and allow the client TLS to terminate at the sensor instead of at the load balancer. An NLB acting as a TCP load balancer allows the sensors to utilize IP interrogation and TLS fingerprinting techniques fully.
The sensors are deployed in two target pools corresponding to the NLB zones. The target pools are distributed across zones for fault tolerance. The target pool mapping to the instance group manager and instances is shown below.
The deployment script also configures a healthcheck in each zone.
As shown in the following screenshot, instance groups as well as instance templates are set up in each zone.
The defined instance template utilizes a default VM instance type of f1-micro. It is recommended to change it (in sensor-deploy.yml) to e2-medium for most production deployments.
An autoscaler group in each zone is also created. The default pool has a minimum of 1 Sensor deployed (and a maximum number of 2 replicas). You can modify the sensor-deploy.yml file to change the number of replicas.
Traffic forwarding rules for each NLB are also provisioned.
ThreatX WAF Sensors
The sensor is available as a GCP image. The automation template deploys VM compute instances in target pools.
Each sensor must have Internet connectivity to the ThreatX cloud to the pull site, certificate, backend (i.e., origin), routing configuration, and security rules. Once the configuration is obtained, the sensor inspects and blocks, tarpits, or interrogates traffic using configuration parameters pulled from the ThreatX cloud. If connectivity to the ThreatX cloud is lost, the sensor continues to operate using its most recent configuration and event log messages are cached locally until connectivity is restored.
The private IP space and NAT Gateway are utilized to enhance Sensor security.
To establish connectivity to the ThreatX cloud, both the tenant name and a Sensor API key must be obtained via the ThreatX management interface.
In addition to the sensors, a bastion or jump host is deployed, as noted in the following figure.
The deployment stack creates multiple different networking components necessary to support the scaled ThreatX deployment. These components are described in more detail in the following sections.
Network and Subnetwork
The deployment creates a network and a small subnetwork by default, as shown in the following figure.
Gateways and Subnets
The sensors must communicate with the ThreatX cloud to obtain configurations. To provide a secure architecture, the private VPC subnets, which house the sensors, communicate via a NAT Gateway to ensure “one-way” communication. The Cloud NAT Gateway is a regional construct.
A Cloud Router is also configured and associated to the Cloud NAT Gateway.
Rules can also be created by default to facilitate http(s) and allow for SSH management traffic to the target sensors. Though SSH traffic rules are provisioned, SSH access to the sensors is not recommended during normal sensor operation. The sensors should have a private IP address, not a public IP address, and be accessible only from the bastion or jump host.
The HTTP(S) and internal traffic provisioned firewall rules are shown below.
Utilizing the deployment template, the stack creation process is relatively straightforward.
Creating the ThreatX Sensor image
Once you obtain the sensor Python package from the ThreatX SOC, you utilize the GCP SDK to create a ThreatX image in your Google project, as shown below.
Here <user_project> is the Google project ID and must be a string without spaces; for example, national-portal-513821.
Once successful, the ThreatX image should be present in your project as shown below.
Modifying the sensor-deploy.yml file
The following figure shows a sample deployment template, sensor-deploy.yml.
The parameter inputs are briefly explained below each parameter. Where possible, the parameters are supplied with default values, which you can adjust to meet your implementation requirements.
The following is a description of a few parameters.
- threatxCustomer: This is your tenant name and is found in the upper right corner of the interface after logging into the ThreatX platform. In the .yml file shown above, the value of the parameter is “lab”.
- threatxApiKey: This can also be generated via the ThreatX interface. It is a one-time generation of the key, so make sure to capture the value.
- threatxSensorTags: Optional standard GCP tags. It is a comma-delimited list of tags that display in the ThreatX Dashboard Sensors table to identify each sensor.
- image: Local project name of the ThreatX image, which is the value of <user_project> when you created the image.
Creating the infrastructure
Once you obtain the image and modified the sensor-deploy.yml file, you can create the ThreatX infrastructure with the following Google SDK command.
Last Updated 2023-03-28