open-appsec
WebsiteManagement PortalPlaygroundGitHub
  • open-appsec Documentation
  • What is open-appsec?
  • open-appsec Video Tutorials
  • Release Notes
  • Getting started
    • Getting Started
    • Start With Kubernetes
      • Install Using Interactive CLI Tool (Ingress NGINX)
      • Configuration Using Interactive CLI Tool
      • Install Using Helm
      • Install Using Helm - new flow (beta)
      • Configuration Using CRDs
      • Configuration Using CRDs - v1beta2
      • Configuration using CRDs - special options for Large Scale Deployments
        • Using appsec class for assigning separate custom resources to specific deployments
        • Using namespace-scoped custom resources
      • Monitor Events
    • Start With Linux
      • Install open-appsec for Linux
      • Using the open-appsec-ctl Tool
      • Configuration Using Local Policy File (Linux)
      • Local Policy File (Advanced)
      • Local Policy File v1beta2 (beta)
      • Monitor Events
    • Start with Docker
      • Install With Docker (Centrally Managed)
      • Install With Docker (Locally Managed)
      • Deploy With Docker-Compose (Beta)
      • Configuration Using Local Policy File (Docker)
      • Local Policy File (Advanced)
    • Using the Web UI (SaaS)
      • Sign-Up and Login to Portal
      • Agents Deployment
      • Connect Deployed Agents to SaaS Management Using Tool (K8s & Linux)
      • Connect Deployed Agents to SaaS Management Using Helm (K8s)
      • Connect Deployed Agents to SaaS Management (Docker)
      • Create a Profile
      • Protect Additional Assets
      • Monitor Events
    • Using the Advanced Machine Learning Model
  • Concepts
    • Agents
    • Management & Automation
    • Security Practices
    • Contextual Machine Learning
  • SETUP INSTRUCTIONS
    • Setup Web Application Settings
    • Setup Custom Rules and Exceptions
    • Setup Web User Response Pages
    • Setup Log Triggers
    • Setup Behavior Upon Failure
    • Setup Agent Upgrade Schedule
  • Additional Security Engines
    • Anti-Bot
    • API Schema Enforcement
    • Data Loss Prevention (DLP) Rules
    • File Security
    • Intrusion Prevention System (IPS)
    • Rate Limit
  • Snort Rules
    • Import Snort Rules
    • Write Snort Signatures
  • HOW TO
    • Configuration and Learning
      • Track Learning and Move From Learn/Detect to Prevent
      • Configure Contextual Machine Learning for Best Accuracy
      • Track Learning and Local Tuning in Standalone Deployments
      • Move From Detect to Prevent in K8s With Many Ingress Rules
  • Deployment and Upgrade
    • Load the Attachment in Proxy Configuration
    • Upgrade Your Reverse Proxy/API Gateway When an Agent is Installed
    • Integration in GitOps CD (K8s)
    • Build open-appsec Based on Source Code
  • Management Web UI
    • Track Agent Status
    • Delete or Reset Management Tenant (SaaS)
    • Disconnect an open-appsec agent from Central Management
  • Integrations
    • About Integrations With 3rd Party Solutions
    • CrowdSec
      • CrowdSec Bouncer Support
      • CrowdSec Intelligence Sharing Using open-appsec Parser/Scenario
    • NGINX Proxy Manager
      • Install NGINX Proxy Manager with open-appsec managed from NPM WebUI
      • Install NGINX Proxy Manager with open-appsec managed from central WebUI (SaaS)
      • Frequently Asked Questions
      • How to Migrate from an Existing NGINX Proxy Manager Deployment and Keep Configuration
    • NPMplus
    • Docker SWAG
      • Install Docker SWAG with open-appsec (locally managed)
      • How to connect locally managed Docker SWAG with open-appsec to WebUI
      • Install Docker SWAG with open-appsec (centrally managed)
      • Deploy Docker SWAG with docker-compose (beta)
      • Frequently Asked Questions
  • Troubleshooting
    • Troubleshooting
    • Troubleshooting Guides
      • Configuration contains ingress/asset with URL which already has asset attached to it in your tenant
      • HTTP Request to Port 80 Not Returning as Expected
      • Agent Fails to Recognize HTTP Transactions with NGINX
      • Agent Not Recognizing Initial HTTP Requests
      • Handling Large Requests (413 Responses)
      • open-appsec on Docker HTTP Transaction Handler Is Set To Ready
      • Traffic Recognition Issue on Single-Core Machine/Connection Timed Out
      • Installing open-appsec on CentOS 7
      • SELinux: checking status and disabling
      • Deploy open-appsec directly on the web server hosting the application to protect
      • object is locked or remote, and therefore cannot be modified
      • Failed to Register to Fog
  • references
    • Agent CLI
    • Event Query Language
    • Events/Logs Schema
    • WAF Comparison Project
Powered by GitBook
On this page
  • Agents
  • Agent Main Components
  • Deployment vehicles
  • Secure Communication
  • Profiles

Was this helpful?

  1. Concepts

Agents

PreviousUsing the Advanced Machine Learning ModelNextManagement & Automation

Last updated 2 months ago

Was this helpful?

open-appsec can be deployed on Kubernetes integrated with NGINX Ingress Controller or Kong or APISIX Gateway. It can also be added NGINX , Kong Gateway, Envoy, APISIX, NGINX Proxy Manager, or SWAG on Docker, and NGINX, Kong, and APISIX on Linux. 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

Agents are small software components that can be easily deployed on top of an existing web server or reverse proxy, without changing existing architecture and while ensuring minimal latency and maximum control.

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. Moreover, 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.

Agent Main Components

Agent's main components are detailed in the following diagram and explained below:

Attachment

The Attachment connects between processes that provide HTTP data and the open-appsec security logic.

The most common attachment is for NGINX (or open-resty, which is based on NGINX, also used by e.g. Kong gateway). 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 is also possible to order the Attachment to ignore specific IP addresses or ranges, which allows for a controlled, gradual deployment. See more details below.

HTTP Transaction handler nano-service

A process (or multiple instances, depending on load) that gets data for processing from the Attachment, executes open-appsec security logic, returns a verdict and issues relevant logs.

Orchestrator

A process in charge of agent registration, obtaining policy updates, software updates and other administrative operations.

Watchdog

A process in charge of making sure that all components are up and running.

Deployment vehicles

open-appsec provides multiple deployment vehicles. All of them include the same agent technology:

Currently, open-appsec supports NGINX, APISIX and Kong Gateway on Kubernetes, Linux and Docker platforms. Additional integrations will follow soon after.

Kubernetes Ingress Controller

  • Helm chart for NGINX Ingress Controller (enhanced with open-appsec)

  • Kubernetes Ingress Controller pod (based on the Ingress-NGINX Controller)

  • open-appsec Agent (as sidecar container in the Ingress Controller pod)

Kubernetes Kong Gateway

  • Helm chart for Kong (enhanced with open-appsec)

  • Kong pod (containing Kong Gateway container and optionally Kong Controller container)

  • open-appsec Agent (as sidecar container in the Kong pod)

Kubernetes APISIXGateway

  • Helm chart for APISIX (enhanced with open-appsec)

  • APISIX pod (containing APISIX Gateway container and optionally APISIX Controller container)

  • open-appsec Agent (as sidecar container in the APISIX pod)

Container setup (e.g. on Docker)

Includes two containers that communicate with each other

  • NGINX, Kong, APISIX, Envoy, NGINX Proxy Manager, SWAG (include open-appsec Attachment)

  • open-appsec Agent

Linux NGINX

An agent installation script for environments that are already running NGINX or Kong on Linux, which installs:

  • open-appsec attachment for NGINX, APISIX or Kong

  • open-appsec Agent

We encourage and provide assistance to anyone that wishes to develop their own Attachments and deployment vehicles.

Secure Communication

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 URLs of Check Point operated public Fog, make sure to have outbound communication allowed from your agent:

  • https://inext-agents.cloud.ngen.checkpoint.com

  • https://downloads.openappsec.io

Profiles

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:

    • Kubernetes

    • Linux

    • Docker

  • 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.

The best-practice recommendation is to create an individual profile in the WebUI for each of your open-appsec deployments. Examples for "deployments" would be e.g.:

- K8s deployment using HELM or installation tool (consisting of one or multiple open-appsec agents) - redundant deployment using Docker on two or more virtual machines (each having it's own agent) protecting the same web assets - redundant embedded deployment on one or multiple redundant Linux machines protecting the same web assets Security-wise this makes sure that only policies for those assets which are protected by specific agents are enforced on those agents (by linking the Assets to only the relevant profile(s)), in addition to having a separate tokens per each deployment and all associated agents. In addition this approach provides the flexibility of being able to configure various settings available on profile-level individually per each deployment, if required.