Upon start, cloud active defense will perform two types of operations:

config update

Every second, Envoy will send a GET /default/default request to controlpanel (in docker-compose). Controlpanel expects a path in the form /namespace/application. This path is properly specified when deploying to kubernetes.

• controlpanel will return decoy config for a specific namespace/application or, if not found, the previously loaded configuration. Also, if you're running in docker-compose, the default config file will always be returned.
• controlpanel will append to the returned decoy config the content of the global config for a specific namespace/application or, if not found, the previously loaded configuration. Also, if you're running in docker-compose, the default config file will always be returned .

If the config content is different from what was last read, Envoy will load the new config and print on the console 'read new config'.

request processing

Every time a request is received, Envoy will call several events, in this order. The standard flow is highlighted in bold:

1. onHttpRequestHeaders:

   • saves some details (url path, cookies) in the global context
   • checks if the request's ip/user-agent/session appears in the blocklist. If yes, executes the configured response.
   • verifies 'inRequest' detect rules for http request header decoys (headers, url, getParams)
   • injects 'inRequest' header decoys

2. onHttpRequestBody (if exists):

   • verifies 'inRequest' detect rules for http request body decoys (postParams, payload)
   • injects 'inRequest' body decoys

3. onHttpResponseHeaders:

   • uses global context to verify 'inResponse' detect rules for http response headers
   • used global context to inject 'inResponse' header decoys

4. onHttpResponseBody (if exists):

   • uses global context to verify 'inResponse' detect rules for http response body
   • used global context to inject 'inResponse' body decoys

5. onHttpStreamDone:

   • for all decoys that triggered detection, send the related alerts.
   • for all decoys that triggered response, update the blocklist.

blocklist synchronization

The (global) blocklist contains ip/user-agent/session combinations used to identify requests from attackers and specifies how to react (for example: drop the request).

Envoy sends new blocklist entries to the controlpanel (which stores them into controlpanel database in blocklist table) and keeps its own local copies.

Every 60 seconds (can be configured via the blocklistReload option), Envoy will send a GET /blocklist request to controlpanel to retrieve the distant copies. This is useful if Envoy crashes at it will reload the list from the storage, or to update the list after a manual intervention (such as an admin unblocking an IP address blocked due to a badly configured response)

going further

Proxywasm sdk

Documentation about proxywasm