GeneralCodeStructure

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

config update

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

• configmanager will return cad-namespace-application.json or, if not found, cad-default.json. This means that the default config file will always be returned if you're running in docker-compose.
• configmanager will append to the returned decoy config the content of config-namespace-application.json or, if not found, config-default.json. This means that the default config file will always be returned if you're running in docker-compose.

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 configmanager (which stores them into local files /data/blocklist/blocklist.json and /data/blocklist/throttlelist.json) and keeps its own local copies.

Every 60 seconds (can be configured via the blocklistReload option), Envoy will send a GET /blocklist request to configmanager 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