WebsiteManagement PortalPlaygroundGitHub

Local Policy File (Advanced)

The local configuration schema explained below is based on the schema version v1beta1. The latest available, significantly enhanced local configuration schema version is v1beta2, documentation for v1beta2 is available here: Local Policy File v1beta2 (beta)

Here you find the full specification for the different configuration sections and elements that can be part of the declarative configuration file including an example for each:

Policies

The policies section defines the default behaviors that will apply to all web resources exposed by the NGINX server, Kong Gateway or APISIX Gateway as well as specific rules for overriding the default behaviour for specific hostname/path combinations.

Example
policies:
  default:
    triggers:
    - appsec-special-log-trigger
    mode: detect-learn
    practices:
    - webapp-default-practice
    source-identifiers: appsec-source-identifiers-sourceip-example
    trusted-sources: appsec-trusted-source-example
    custom-response: appsec-web-user-response-example
    exceptions:
    - appsec-exception-example
  specific-rules:
  - host: web.server.com/example
    triggers:
    - appsec-special-log-trigger
    mode: prevent-learn
    practices:
    - webapp-best-practice
    source-identifiers: appsec-source-identifiers-sourceip-example
    trusted-sources: appsec-trusted-source-example
    custom-response: appsec-web-user-response-example
    exceptions:
    - appsec-exception-example
  - host: web.server.com/another-example
    triggers:
    - appsec-special-log-trigger
    mode: prevent-learn
    practices:
    - webapp-best-practice
    source-identifiers: appsec-source-identifiers-sourceip-example
    trusted-sources: appsec-trusted-source-example
    custom-response: appsec-web-user-response-example
    exceptions:
    - appsec-exception-example
Specification

default

  • mode string enum - security engines operation mode. Blocking will only happen in prevent-learn mode

    • prevent-learn / detect-learn / prevent / detect / inactive (note that prevent and detect are just aliases for prevent-learn and detect-learn)

  • practices array of strings - defines which security engines to activate and their specific settings (Although this is an array already there cannot be multiple practices of the same kind specified here for now!)

    • reference to Practice resource(s)

  • triggers array of strings - defines logging verbosity and destination (stdout, syslog, cloud, etc) (Although this is an array for now only a single trigger is supported!)

    • reference to LogTrigger resource(s)

  • custom-response string - defines prevent mode behaviors upon decision to block: HTTP response code, block page, http redirect

    • reference to CustomResponse resource

  • source-identifiers string - defines how ML engine will distinguish between sources based on IP address, X-Foward-For, Key in Header/Cookie/JWT

    • reference to SourcesIdentifier resource

  • trusted-sources string - defines which traffic sources are very unlikely to be malicious. Used for Machine Learning engine.

  • exceptions arrays of strings - defines exceptions to be applied based on e.g. countryCode, countryName, sourceIP, URL, hostName, sourceIdentifier

    • reference to Exception resource(s)

specific-rules list list of one or more per-host (ingress rule) policies that will override the defaults above

  • host string - policy will apply to this host

    • network path (exactly as appear in ingress rules)

  • All other keys can be used same as decribed above for default.

Practices

Practice resources define which security engines will be active and what their settings are.

Example 
practices:
  - name: webapp-best-practice
    openapi-schema-validation:
      files: []
      override-mode: 'prevent'
    snort-signatures:
      files: []
      override-mode: 'prevent'
    web-attacks:
      max-body-size-kb: 1222
      max-header-size-bytes: 44343
      max-object-depth: 2111
      max-url-size-bytes: 34434
      minimum-confidence: high
      override-mode: 'prevent'
      protections:
        csrf-enabled: prevent
        error-disclosure-enabled: prevent
        non-valid-http-methods: true
        open-redirect-enabled: prevent
    anti-bot:
      injected-URIs: []
      validated-URIs: []
      override-mode: 'prevent'
Specification

  • web-attacks - open-appsec ML engine settings

    • override-mode string enum - allows overriding the mode defined at the Policy level for this specific engine (when set to as-top-level the value will be inherited from mode setting in the policy)

      • prevent-learn / detect-learn / prevent / detect / inactive / as-top-level

    • minimum-confidence string enum, default: high - defines which security engines to activate and their specific settings

      • medium / high / critical

    • max-url-size-bytes integer, default: 32768

    • max-object-depth integer, default: 40

    • max-body-size-kb integer, default: 102400

    • max-header-size-bytes integer, default: 32768

    • protections - settings for various advanced protections:

      • csrf-enabled string, default: inactive - Cross Site Request Forgery protection

        • prevent-learn / detect-learn / prevent / detect / inactive

      • error-disclosure-enabled string, default: inactive - Prevent disclosure of technical information to the attacker in server error messages

        • prevent-learn / detect-learn / prevent / detect / inactive

      • open-redirect-enabled string, default: inactive - Protect against URL redirection to untrusted sites

        • prevent-learn / detect-learn / prevent / detect / inactive

      • non-valid-http-methods boolean, default: false - Prevent attacker from sending requests with unsafe HTTP methods

        • true / false

  • open-api-schema-validation (currently not supported yet, will be added soon)

    • configmap array of strings - specify configmap(s) containing the OpenAPI schema definitions

    • override-mode enum - allows overriding the mode defined at the Policy level for this specific engine (when set to as-top-level the value will be inherited from mode setting in the policy)

      • prevent-learn / detect-learn / prevent / detect / inactive / as-top-level

  • anti-bot (currently not supported yet, will be added soon)

    • override-mode enum - allows overriding the mode defined at the Policy level for this specific engine (when set to as-top-level the value will be inherited from mode setting in the policy)

      • prevent-learn / detect-learn / prevent / detect / inactive / as-top-level

    • injected-URIs array of strings - Provide URL(s) where Anti-Bot check is injected with GET request

    • validated-URIs array of strings - Provide URL(s) where result of Anti-Bot check is received from with POST request

  • snort-signatures (currently not supported yet, will be added soon)

    • override-mode enum - allows overriding the mode defined at the Policy level for this specific engine (when set to as-top-level the value will be inherited from mode setting in the policy)

      • prevent-learn / detect-learn / prevent / detect / inactive / as-top-level

    • configmap array of strings - specify configmap(s) containing snort signatures

Custom Response

Optional custom responses can be configured to return in prevent mode either a customizable block page or the desired response code only. The custom responses than can be referenced within one or more policy elements.

Examples
Specification

  • mode enum - engine will take one of these actions upon decision to block request

    • block-page - send HTML with text to client + HTTP response code

    • response-code-only - send only response code

  • message-title string - title of block page that will be displayed only in case mode is block page and engine decided to block

  • message-body string - content of block page that will be displayed only in case mode is block page and engine decided to block

  • http-response-code integer between 100-599 - http code that will be returned to client upon engine decision to block; default is 403 - HTTP Forbidden

Log Trigger

Optional log trigger elements can be used to configure custom logging requirements. They can then be referenced within one or more policy elements.

Example
Specification

  • access-control-logging - configure logging for Access Control events

    • allow-events boolean, default: false - log access control allow events

      • true / false

    • drop-events boolean, default: true - log access control drop events

      • true / false

  • additional-suspicious-events-logging configure additional logging for suspicious events based on a selectable minimum severity-level

    • enabled boolean default: true - enable/disable additional suspicious events logging

      • true / false

    • minimum-severity string enum, default: high - select minimum severity level

      • high / critical

  • appsec-logging configure logging for open-appsec events (threat prevention, machine learning)

    • detect-events boolean, default: true - log detected events

      • true / false

    • prevent-events boolean, default: true - log prevented events

      • true / false

    • all-web-requests boolean, default: false - log all web requests (has performance impact!)

      • true / false

    • extended-logging

      • url-path boolean, default: true - log URL path

        • true / false

      • url-query boolean, default: true - log URL query

        • true / false

      • http-headers boolean, default: false - log the HTTP headers (has performance impact!)

        • true / false

      • request-body boolean, default: false - log the request body (has performance impact)

        • true / false

  • log-destination

    • cloud boolean, default: false - enable or disable logging to the appsec-open Cloud Service (relevant when being connected to SaaS Mgmt WebUI)

      • true / false

    • file string - define file path to save logs to (local path from root directory of the open-appsec container, could also refer to a mountPath for a mounted Persistent Volume in the container)

    • stdout - configure logging to standard-out

      • format string enum - define the desired log format

        • json / json-formatted - select between formatted or standard json

    • syslog-service objects array - define one or more syslog servers and corresponding ports to send logs to

      • address string - Syslog server IP address

      • port integer - Syslog server port

    • cef-service - allows sending files to a log destination in CEF format

      • address string - CEF server IP address

      • port integer - CEF server port

      • proto string enum Select the correct protocol

        • tcp / udp - Chose TCP or UDP protocol

Exceptions

Optional exception elements can be used to configure custom exceptions. They can then be referenced within one or more policy elements.

Example
Specification

Define a list of actions-objects with the corresponding parameters to match to configure flexible custom exceptions/rules, each having the following configurable keys:

  • action string enum - Action to be performed when exception matches

    • skip / accept / drop / suppressLog

  • sourceIp string array - Source IP(s)

  • url string array - URL(s)

  • sourceIdentifier string array - Identified source(s)

  • protectionName string array - Protection(s)

  • paramValue string array - Parameter value(s)

  • paramName string array - Parameter name(s)

  • hostName string array - Host name(s)

  • countryCode string array - Country code(s)

  • countryName string array - Country name(s)

  • comment string - Comment for the exception

Trusted Sources

Optional trusted sources can be defined, for which the machine learning engine will assume, that the traffic originating from them is benign and learn accordingly.

Trusted sources elements can then be referenced within the policies section.

Example
Specification

Define trusted sources by referencing the source identifiers custom resources as well as setting the minimum amount of sources that need to be observed by the behavioural ML engine sending certain identical traffic patterns in order to learn this behaviour as being benign.

  • minNumOfSources integer - Minimum amount of sources having to be observed sending same traffic patterns to learn behaviour as benign.

  • sourcesIdentifiers string array - Specify one or more source identifiers

Source Identifiers

Source Identifiers can be used to define how open-appsec distinguishes between different sources, e.g. based on source IP addresses, x-forwarded-for header content, etc.

Examples
Specification

Define list of one or more specific source identifiers that can be used in trusted sources custom resources.

  • identifiers objects array - provide single source identifier Note: Although this is an array currently only adding single source identifier here is supported. (Later an option is planned to be added to provide multiple source-identifiers here, so that if the first one is not found in an http request then the next one would be checked.)

  • source-identifier string enum - Specify the source identifier type of which the content shall be matched

    • headerkey, JWTKey, cookie, sourceip, x-forwarded-for

  • value string array - Content to match the specified sourceIdentifier type

    • For types headerkey, cookie and JWTKey provide the fieldname that designates user

    • For type Source IP no value is required

    • For type x-forwarded-for provide previous proxy hops if there are any

Schema file

Here you find the full schema file for the local declarative configuration yaml file. This also shows you which fields are required and which are optional

Schema file for local policy file

PreviousConfiguration Using Local Policy File (Linux)NextLocal Policy File v1beta2 (beta)

Last updated

Was this helpful?