Configuration
All HAProxy Enforcer configuration are placed in px_haproxy.lua
file, which is located in /usr/local/lib/
directory.
Required HUMAN Module Configuration
The following parameters are mandatory:
- px_enabled
- px_appId
- px_cookie_secret
- px_auth_token
-- ## Required Parameters ##
_M.px_enabled = true
_M.px_appId = "<PX_APP_ID>"
_M.auth_token = "<PX_AUTH_TOKEN>"
_M.cookie_secret = "<COOKIE_ENCRYPTION_KEY>"
px_app_id
The application ID. Required to initialize the HAProxy Enforcer.
_M.px_appId = "<PX_APP_ID>"
px_auth_token
The token used for authorization with the HUMAN backend. Required to initialize the HAProxy Enforcer.
_M.auth_token = "<PX_AUTH_TOKEN>"
px_cookie_secret
The secret used to encrypt and decrypt the risk cookie. Required to initialize the HAProxy Enforcer.
_M.cookie_secret = "<COOKIE_ENCRYPTION_KEY>"
px_enabled
This boolean serves as an on/off switch for the entire module, providing a way to enable and disable all Enforcer capabilities quickly and easily.
_M.px_enabled = true
Monitor / Block Mode Configuration
By default, the HUMAN plugin is set to monitor mode.
_M.block_enabled = false
Adding the _ M.block_enabled flag and setting it to true in the px_haproxy.lua
 file activates the module to enforce blocking. This means the HUMAN Module blocks requests that exceed the block score threshold. If a request receives a risk score that is equal to or greater than the block score, a block page is displayed.
Debug Mode
Enables debug logging mode.
Default:Â false (disabled)
_M.px_debug = true
When Enabled, HUMAN debug messages should be in the following template:
- For debug messages -Â
[PerimeterX - DEBUG] [APP_ID] - MESSAGE
- For error messages -Â
[PerimeterX - ERROR] [APP_ID] - MESSAGE
Allowlist
Allowing (bypassing enforcement) is configured in the px_haproxy.lua
 file.
Several filters can be configured:
_M.whitelist_uri_full = { _M.custom_block_url },
_M.whitelist_uri_prefixes = {},
_M.whitelist_uri_suffixes = {'.css', '.bmp', '.tif', '.ttf', '.docx', '.woff2', '.js', '.pict', '.tiff', '.eot', '.xlsx', '.jpg', '.csv', '.eps', '.woff', '.xls', '.jpeg', '.doc', '.ejs', '.otf', '.pptx', '.gif', '.pdf', '.swf', '.svg', '.ps', '.ico', '.pls', '.midi', '.svgz', '.class', '.png', '.ppt', '.mid', '.webp', '.jar'},
_M.whitelist_ip_addresses = {},
_M.whitelist_ua_full = {},
_M.whitelist_ua_sub = {}
Filter Sensitive Headers
A list of sensitive headers configured to prevent specific headers from being sent to HUMAN servers (headers in lowercase). Filtering cookie headers for privacy is set by default.
Default:Â cookie, cookies
Example:
_M.sensitive_headers = {'cookie', 'cookies', 'secret-header'}
Enabled Routes
Allows you to define a set of routes on which the plugin will be active. An empty list sets all routes in the application as active.
Default:Â Empty list (all routes are active)
Example:
_M.enabled_routes = {'/blockhere'}
Sensitive Routes
A list of route prefixes and suffixes. The HUMAN module always matches the request URI with the prefixes list and suffixes list. When there is a match, the HUMAN  module creates a server-to-server call, even when the cookie is valid and the risk score is low.
Default:Â Empty list
Example:
_M.sensitive_routes_prefix = {'/login', '/user/profile'}
_M.sensitive_routes_suffix = {'/download'}
Customize Default Block Page
The HUMAN  default block page can be modified by injecting custom CSS, JavaScript and a custom logo to the block page.
Default:Â nil
Example:
_M.custom_logo = "http://www.example.com/logo.png"
_M.css_ref = "http://www.example.com/style.css"
_M.js_ref = "http://www.example.com/script.js"
Redirect to a Custom Block Page URL
Customizes the block page to meet branding and message requirements by specifying the URL of the block page HTML file. The page can also implement CAPTCHA.
Default:Â nil
Example:
_M.custom_block_url = '/block.html'
Note
This URI is allowed automatically underÂ
_M.Whitelist['uri_full']
 to avoid infinite redirects.
Redirect on Custom URL
The _M.redirect_on_custom_url
 boolean flag to redirect users to a block page.
Default:Â false
Example:
_M.redirect_on_custom_url = false
By default, when a user exceeds the blocking threshold and blocking is enabled, the user is redirected to the block page defined by the _M.custom_block_url
 variable. The defined block page displays a 307 (Temporary Redirect) HTTP Response Code.
When the flag is set to false, a 403 (Unauthorized) HTTP Response Code is displayed on the blocked page URL.
Setting the flag to true (enabling redirects) results in the following URL upon blocking:
Text
http://www.example.com/block.html?url=L3NvbWVwYWdlP2ZvbyUzRGJhcg==&uuid=e8e6efb0-8a59-11e6-815c-3bdad80c1d39&vid=08320300-6516-11e6-9308-b9c827550d47
Setting the flag to false does not require the block page to include any of the examples below, as they are injected into the blocking page via the HUMAN NGINX Module.
Note
The URL variable should be built with the URL-encoded query parameters (of the original request) with both the original path and variables base64-encoded (to avoid collisions with block page query params).
Custom Block Pages Requirements
As of version 4.0, Captcha logic is handled through the JavaScript snippet and not through the enforcer.
Users who have Custom Block Pages must include the new script tag and a new div in the .html block page. For implementation instructions refer to the appropriate links below:
Redirect to Referer
Indicates whether the user is redirected from the challenge page to the referrer page after successfully solving the challenge.
Default:Â false
Example:
_M.redirect_to_referer = true
Changing the Minimum Score for Blocking
This value should not be changed from the default of 100 unless advised by HUMAN.
Default blocking value:Â 100
Example:
_M.blocking_score = 100
First-Party Prefix
Allows you to define a custom prefix for First-Party routes.
Default:Â nil
Example:
_M.first_party_prefix = 'resources'
To define the First-Party Prefix:
-
In yourÂ
px_haproxy.lua
 file, set theÂ_M.first_party_prefix
property to the desired prefix value. For example:_M.first_party_prefix = 'resources'
-
Open the HUMAN Console.
-
Go toÂ
Admin
 ->ÂApplications
. -
Open theÂ
Snippet
 section. ActivateÂFirst-Party
 (if not in First-Party already), and clickÂEdit
 next to the Copy Snippet button. -
In the pop-up that opens there are two routes beginning withÂ
/<appId without PX>
. Copy both routes to a side document to use in the next steps. -
ClickÂ
Advanced Configuration
. -
Under Sensor, copy the first route from step 5 and add the prefix you added in step 1 to the beginning of of the route.
For example:Â
/resources/<appId without PX>/init.js
-
Under Server copy the second route from step 5 and the prefix you added in step 1 to the beginning of the route.
For example:Â
/resources/<appId without PX>/xhr
-
ClickÂ
Save Changes
. -
ClickÂ
Copy Snippet
 and update the JS Sensor snippet of your site with the updated one.
Advanced Blocking Response Support
Enables/disables support for Advanced Blocking Response.
Default:Â true (enabled)
Example:
_M.advanced_blocking_response = false
Proxy Support
Sets a proxy server for all the enforcer's outgoing calls.
Default:Â nil
Example:
_M.proxy_url = 'http://localhost:8008'
Proxy Authorization
If proxy support is enabled, allows you to set a proxy authorization header.
Default:Â nil
Example:
_M.proxy_authorization = 'top-secret-header-value'
Custom Cookie Header
When set, this property specifies a header name that will be used to extract the HUMAN cookie from, instead of the Cookie header.
Note
Using a custom cookie header requires client-side integration to be done as well. Please refer to the relevant docs for details.
Default:Â nil
Example:
_M.custom_cookie_header = 'x-px-cookies'
Bypass Monitor Mode Header
When set, allows you to test the blocking flow of an enforcer, while in monitoring mode. When the enforcer receives a request that has this configured header name with the value of 1
, it will behave as though it is in active blocking mode. For instance, requests with this header and bad user-agents (e.g., PhantomJS/1.0
) will return with a block page.
Default:Â nil
_M.bypass_monitor_header = 'x-px-block'
Credential Intelligence
The following configurations are used to enable HUMAN Credential Intelligence offering:
Login Credentials Extraction
This feature extracts credentials (hashed username and password) from requests and sends them to HUMAN as additional info in risk / activity api calls. The feature can be toggled on and off. The settings are adjusted by modifying a credentials JSON file.
Enable Login Credentials Extraction
Default: false (disabled)
_M.px_enable_login_creds_extraction = true
Credentials JSON file
Sets a full path to credentials JSON file
Default: nil (none)
_M.px_login_creds_settings_filename = "/etc/haproxy/creds.json"
Credentials JSON file contains an array of CI items. Each item must contain the following fields:
- id : unique number
- method : string contains a method, supported methods: "post", "put"
- sent_through : contains one of the following strings: "body", "header", "query-param"
- path : string with URL path, must start with "/"
- user_field : string with username field name
- pass_field : string with password field name
This is an example of `/etc/creds.json` file. It includes an array of JSON objects containing the following properties:
{
"features": {
"credentials": {
"items": [
{
"id": 0,
"method": "post",
"path": "/login",
"sent_through": "body",
"pass_field": "password",
"user_field": "username"
}, {
"id": 1,
"method": "post",
"path": "/login-header",
"sent_through": "header",
"pass_field": "password",
"user_field": "username"
}, {
"id": 2,
"method": "put",
"path": "/login-params",
"sent_through": "query-param",
"pass_field": "password",
"user_field": "username"
}
]
}
}
}
Credentials Intelligence Version
Sets Credentials Intelligence protocol version
Default: 'v2'
_M.px_credentials_intelligence_version = 'v2';
IP Headers
A list of trusted headers that specify an IP to be extracted.
Default: Empty list
_M.ip_headers = {"X-Forwarded-For"}
Test Block Flow on Monitoring Mode
When set, allows you to test the blocking flow of an enforcer, while in monitoring mode. When the enforcer receives a request that has this configured header name with the value of 1, it will behave as though it is in active blocking mode. For instance, requests with this header and bad user-agents (e.g., PhantomJS/1.0) will return with a block page.
Default: Empty
_M.bypass_monitor_header = 'x-px-block'
Updated 12 days ago