Gateways & Agents
Last updated
Was this helpful?
Last updated
Was this helpful?
CloudGuard WAF can be deployed in several ways: Virtual Machine on VMware or AWS/Azure, Docker Container, Agent for Linux, Kubernetes Ingress Controller, ScaleSet/Auto-Scaling group in AWS/Azure. All deployment vehicles share the same basic agent technology. In this section we will explain how agents work and what is the difference between the different deployment vehicles.
Agents are small software components that that can be easily deployed on top of an existing web server, reverse proxy or Kubernetes ingress, without changing existing architecture and while ensuring minimal latency and maximum control. In addition, Check Point provides:
A pre-packaged Virtual Machine that includes both operating system, reverse proxy and the agent.
A helm chart available to deploy a prepackaged Kubernetes ingress controller (NGINX) together with the CloudGuard WAF agent (integrated as sidecar).
As security processing is done locally sensitive data does not leave the protected environment and there is no need to share certificates and private keys with third parties. More over, there is no dependency on 3rd party uptime for processing traffic.
Agents can be managed by a master called Fog. The Fog is a SaaS component that provides registration, policy update, configuration update, software updates, logging and learning data synchronization. Check Point operates highly available and scalable Fogs in several regions in the world.
Agents get all updates automatically and there is no need to upgrade them manually. It is possible to control the upgrade schedule.
Agents are designed to act stand-alone and will operate without disruption to traffic and security enforcement even when Fog is unreachable. You can also run as many agents to support your load as needed with no license constraints.
When Fog is unreachable some central administrative functions are not available: software and policy updates, lPS updates, logging to cloud and synchronization of learning data between agents. Logs will be kept locally in a configurable cyclic buffer and be relayed when communication resumes. It also possible to configure logging to a local syslog server.
Agents main components are detailed in the following diagram and explained below:
The Attachment connects between processes that provide HTTP data and the CloudGuard WAF security logic. It is open technology and Check Point provides open source code for it.
The most common attachment is for NGINX. It is a small dynamically loadable module that runs in the process space of NGINX acting as Web Server, Reverse proxy, Kubernetes ingress or API gateway. The Attachment gets HTTP data (URL, Header, Body, Response) from the hosting process and delivers it to the HTTP Transaction handler. The attachment does not keep any state and has no security logic.
To deal with potential issues where the HTTP Transaction handler is not responding, the Attachment implements a retry mechanism and a configurable fail-open/fail-close mechanism.
It also possible to order the Attachment to ignore specific IP addresses or ranges, which allows for a controlled, gradual deployment. See more details below.
A process (or multiple instances, depending on load) that gets data for processing from the Attachment, executes CloudGuard WAF security logic, returns a verdict and issues relevant logs.
A process in charge of agent registration, obtaining policy updates, software updates and other administrative operations.
A process in charge of making sure that all components are up and running.
CloudGuard WAF provides multiple deployment vehicles. All of them include the same agent technology:
Gaia OS - Check Point Linux-based hardened operating system. Featuring CLI and WebUI for configuration of various platform and networking aspects
Reverse Proxy
CloudGuard WAF Agent
Helm chart
Kubernetes Ingress Controller pod (based on the Ingress-NGINX Controller)
CloudGuard WAF Agent (as sidecar container in the Ingress Controller pod)
Include two docker containers that communicate with each other
NGINX (includes Cloud Guard WAF Attachment)
CloudGuard WAF Agent
An agent installation script for environment that are already running NGINX on Linux, which installs:
CloudGuard WAF attachment for NGINX
CloudGuard WAF Agent
Check Point encourages and provides assistance to anyone that wishes to develop their own Attachments and deployment vehicles based on CloudGuard WAF Agent.
Agents/Gateways communicate with the Fog over encrypted and authenticated secure channel.
Agent/Gateway is using encrypted communication over HTTP/TLS (Port 443)
One time agent registration is done using a 256bit key
The Agent/Gateway receives a unique agent key from the Fog that is used for identification
Authentication is based on OAuth 2.0 (RFC 6479)
The agent periodically asks for an updated JSON Web Token (JWT)
List of IP addresses and URLs of Check Point operated regional public Fogs can be found in the management portal, under Support->FAQ
Agents are associated with a Profile that simplifies management and allows applying the same settings to multiple agents. When you create the first Web Application or Web API asset using the Wizard, a Profile is automatically created. You can later re-use this profile or create a new one.
Profiles determine the following shared settings:
Type of deployment: VM (AWS, Azure, VMWare vSphere), Kubernetes Ingress Controller, Docker, Linux
Registration Token for new Agents
Agent upgrade Mode: Automatic, Scheduled, Manual
SSL and Private Keys storage mode: On Gateway, in Public Cloud secure storage
Advanced settings such as max number of agents that can connect to a profile
It is possible to delete an agent so that it will no longer be able to connect to the Fog.
Profiles also allow granular policy enforcement. It is possible to select only specific profiles during the action of "Enforce Policy" after configuration changes have been made. Only agents connected to these profiles will receive the policy changes.
