Allows you to manage the settings of the MLC module.
Settings are managed using specially designed queries. The general conventions (authorization, response codes, the *_hash methods and paginated selection) are described in the relevant section.
The general rules for writing the value of a host and of a URL apply to the options of the MLC.
Request example:
curl http://api.example.com:8080/mlc/v1/get_mlc_settings --header 'Content-type: application/json' --data '{"key": "%PRODUCT KEY%"}'
Only the parameters that are filled in are returned. Virtual hosts in the response are converted to punycode. If the zone is not set in an element of brute_bf_detect, the value ["query", "body"] is returned for it.
Response format:
{
"status": "success",
"timestamp": integer,
"active": boolean,
"ml_enable": boolean,
"ti_exchange_disable": boolean,
"openapi_hosts": [string, ...],
"ddos_enable": boolean,
"ddos_wl_ip": [string, ...],
"ddos_wl_url": [string, ...],
"ddos_interval": integer,
"ddos_latest_only": boolean,
"ddos_send_possible": boolean,
"brute_enable": boolean,
"brute_wl_ip": [string, ...],
"brute_wl_host": [string, ...],
"brute_bf_detect": [object, ...],
"brute_interval": integer,
"brute_min_val": integer,
"brute_latest_only": boolean,
"brute_send_possible": boolean,
"comment": string
}
or (in the case where the data is missing)
{"status": "none"}
or (in case of an error)
{"status": "fail", "description": "%DESCRIPTION%"}
Response example:
{
"status": "success",
"timestamp": 1719335019,
"active": true,
"ml_enable": true,
"ti_exchange_disable": false,
"openapi_hosts": ["example.com"],
"ddos_enable": true,
"ddos_wl_ip": ["127.0.0.1"],
"ddos_wl_url": ["example.com/feed"],
"ddos_interval": 120,
"ddos_latest_only": true,
"ddos_send_possible": true,
"brute_enable": true,
"brute_wl_ip": ["127.0.0.1"],
"brute_wl_host": ["example.com"],
"brute_bf_detect": [{"url": "*", "brute": true, "flood": false, "zone": ["query", "body"], "condition": {"body": ["auth_form", "user_login"]}}],
"brute_interval": 30,
"brute_min_val": 10,
"brute_latest_only": true,
"brute_send_possible": true,
"comment": "my settings"
}
Request example:
curl http://api.example.com:8080/mlc/v1/set_mlc_settings --header 'Content-type: application/json' --data '{
"key": "%PRODUCT KEY%",
"set": {
"active": true,
"ml_enable": true,
"ti_exchange_disable": false,
"openapi_hosts": ["example.com"],
"ddos_enable": true,
"ddos_wl_ip": ["127.0.0.1"],
"ddos_wl_url": ["example.com/feed"],
"ddos_interval": 120,
"ddos_latest_only": true,
"ddos_send_possible": true,
"brute_enable": true,
"brute_wl_ip": ["127.0.0.1"],
"brute_wl_host": ["example.com"],
"brute_bf_detect": [{"url": "*", "brute": true, "flood": false, "zone": ["query", "body"], "condition": {"body": ["auth_form", "user_login"]}}],
"brute_interval": 30,
"brute_min_val": 10,
"brute_latest_only": true,
"brute_send_possible": true,
"comment": "my settings"
}
}'
Response example:
{"status": "success"}
or (in case of an error)
{"status": "fail", "description": "%DESCRIPTION%"}
When the value is false, the settings are deactivated.
"active": true
Activation of the analysis by the machine learning module for all requests that are not blocked on the Filter.
The analysis of requests is performed based on a copy of the traffic received from the Filter. If the
waf_autobanoption (automatic IP address blocking option) is enabled on Filter, it also applies to attacks detected by the MLC module (detected attacks will result in IP address blocking, just as if the request had been blocked on Filter itself).Enabling the option significantly increases the consumption of hardware resources by the MLC server.
"ml_enable": true
Exchanges threat intelligence about detected attacks with Mikiri IPG API. Each report is three values, in this order:
| Position | Content |
|---|---|
0 |
Client IP address |
1 |
Block type. 7 is Brute-force, 9 is Flood, 10 is DDoS or Web scraping |
2 |
Description: Brute-force, Flood, DDoS or Web scraping |
DDoS and Web scraping share block type 10. The description tells them apart. The block types are the same as in Getting the event type specification.
{
"%CID%": [
["203.0.113.10", 7, "Brute-force"],
["203.0.113.11", 9, "Flood"],
["203.0.113.12", 10, "DDoS"],
["203.0.113.13", 10, "Web scraping"]
]
}
The value true stops these requests. Omitted or false keeps the exchange on. Attacks continue to be stored in Mikiri WAF.
To turn the exchange back on, set false or reset the parameter with null.
"ti_exchange_disable": true
Activation/deactivation of DDoS attack detection and website scraping attempts.
"ddos_enable": true
The option defines a list of IP addresses for which the functionality will be deactivated.
IPv4/IPv6 addresses, CIDR (for example, 10.10.10.1/24) address ranges are allowed.
"ddos_wl_ip": ["10.10.10.1", "1.1.1.0/24", "1.1.1.0-1.1.2.254"]
The option defines a list of URL addresses for which the DDoS attack detection functionality will be deactivated.
Strict matching and wildcard values are allowed: example.com, .example.com, *.example.com, *.
It is prohibited to use values for the option
*or*/, but it is allowed to use*/login.phpto deactivate analysis for any domain with the path/login.php.
"ddos_wl_url": [
"example.com",
"example.com/feed",
"*.example.com/feed",
"*/feed"
]
The time interval (in seconds) during which the requests are analyzed. Allowed values are from 1 to 180.
If the value is empty, the default value of 120 seconds will be set.
"ddos_interval": 120
Activation of the transmission to the API of only the last blocked request for each IP address. When the value is false, all blocked requests for each IP address are transmitted to the API.
"ddos_latest_only": true
Activation of the mechanism for transmitting Possible DDoS events to the API. If the value is false, requests will not be transmitted to the API.
The Possible prefix is added to the attack name if its type has not been reliably established.
"ddos_send_possible": true
Activation/deactivation of the brute-force attack detection functionality.
"brute_enable": true
The option defines a list of URLs for which brute-force and flood attacks will be detected.
Strict matching and wildcard values are allowed for the domain: example.com, .example.com, *.example.com, *.
Additional options are available for more flexible configuration of the conditions for launching the analysis engine.
Required:
url - the URL for which brute-force and flood attacks will be detected;
brute - activates the detection of brute-force attacks for the specified URL;
flood - activates the detection of flood attacks for the specified URL. Using brute and flood with the same value at the same time is not allowed.
Optional:
zone - allows you to set a zone for analysis (QUERY, BODY). If both zones are specified, the request analysis will be performed in parallel for both the QUERY zone and the BODY zone. If the value is empty, the analysis will be activated for both zones.
"zone": ["query", "body"]
condition - allows you to set an additional condition that sends only those requests for analysis that contain the specified argument (for the QUERY zone) or the field name (for the BODY zone). The option values are combined according to the logical "and" principle. If no additional conditions are specified, all requests will be included in the sample for analysis in the specified zone.
"zone": ["body"], "condition": {"body": ["auth_form", "user_login"]}
This means that the request analysis mechanism will be activated only for queries where the auth_form and user_login fields with any values are present in the BODY zone.
"zone": ["query", "body"], "condition": {"query": ["user"], "body": ["auth_form", "user_login"]}
This means that the request analysis mechanism will be activated both for queries that contain the user argument with any value in the QUERY zone for queries that have the auth_form and user_login fields with any values in the BODY zone.
"brute_bf_detect": [
{
"url": "example.com/login.php",
"brute": true,
"flood": false,
"zone": ["body"],
"condition": {"body": ["auth_form", "user_login"]}
},
{
"url": "example.com/abc",
"brute": false,
"flood": true,
"zone": ["query", "body"],
"condition": {"query": ["user"], "body": ["auth_form", "user_login"]}
}
]
The option defines the list of domains for which the brute-force attack detection mechanism will be deactivated.
Strict matching and wildcard values (except for *) are allowed: example.com, .example.com, *.example.com.
"brute_wl_host": [
"example.com",
".example.org",
"*.example.us"
]
The option defines the list of IP addresses for which the brute-force attack detection mechanism will be deactivated.
IPv4/IPv6 addresses, CIDR (for example, 10.10.10.1/24) address ranges are allowed.
"brute_wl_ip": [
"10.10.10.1",
"1.1.1.0/24",
"1.1.1.0-1.1.2.254"
]
The time interval (in seconds) during which the requests are analyzed. Allowed values are from 1 to 180.
If the value is empty, the default value of 30 seconds will be set.
"brute_interval": 30
The number of requests from each specific IP address, upon reaching which the analysis for attack indicators is activated. Allowed values are from 1 to 900.
If the value is empty, the default value of 10 requests will be set.
"brute_min_val": 10
Activation of the transmission to the API of only the last blocked request for each IP address. When the value is false, all blocked requests for each IP address are transmitted to the API.
"brute_latest_only": true
Activation of the mechanism for transmitting events with the type Possible Brute-force/Possible Flood to the API. If the value is false, requests will not be transmitted to the API.
The Possible prefix is added to the attack name if its type has not been reliably established.
"brute_send_possible": true
The option defines the list of domains for which specifications in the OpenAPI format will be automatically generated.
Strict matching and wildcard values are allowed: example.com, .example.com, *.example.com, *.
"openapi_hosts": [
"example.com",
"*.example.uk"
]
Comment.
"comment": "my settings"
The method allows you to check whether the data has changed without downloading it in full. More detailed information is available in the relevant section.
Request example:
curl http://api.example.com:8080/mlc/v1/get_mlc_settings_hash --header 'Content-type: application/json' --data '{"key": "%PRODUCT KEY%"}'
Response example:
{"status": "success", "hash": "8ddd2b342d3190a866ee35afb249919a"}
or (in the case where the data is missing)
{"status": "none"}
or (in case of an error)
{"status": "fail", "description": "%DESCRIPTION%"}
Request example:
curl http://api.example.com:8080/mlc/v1/set_mlc_settings --header 'Content-type: application/json' --data '{
"key": "%PRODUCT KEY%",
"del": ""
}'
Response example:
{"status": "success"}
or (in case of an error)
{"status": "fail", "description": "%DESCRIPTION%"}