Flex Gateway新着情報
Governance新着情報
Monitoring API ManagerThis release contains the following fixed issue:
Client failed when the value of the connection header was neither keep-alive
nor close
. (SE-12165)
This release contains the following enhancement:
A summary log (rtfSidSummary
) is generated, which contains a list of rule instances (rule ID, API, method, direction, and count) where at least one SID rule was triggered during the one-minute collection interval. See Sensitive Information Detection for more information.
This release contains the following known issue:
Sensitive information detection is not bi-directional. When you configure the WAF policy and enable the Detect sensitive information option for Request Rulesets and also enable the Detect sensitive information option for Response Rulesets, the response does not get scanned for sensitive information detection.
Workaround: If you need to enable SID for responses, de-select the Detect sensitive information option for requests.
When you configure a WAF policy, there is a new option to enable sensitive information detection (SID) for the request and response bodies. For more information, see Create a Web Application Firewall Security Policy.
In a Runtime Fabric configured with a DoS policy, you can manage blocked IP addresses. For more information, see Manage Blocked IP Addresses in Runtime Fabric.
The issue where Edge did not honor the Read Request Time-out configuration setting of the Runtime Fabric inbound traffic configuration is fixed.
The issue where Edge failed to route requests to the application when the client (through the request header) asserts Transfer-Encoding: chunked
is fixed.
You can now configure web application firewall policies for Runtime Fabric inbound traffic to provide protection at the Web application level. For more information, see Web Application Firewall Security Policy.
(MSG-6502) The maximum response message body is 512 KB. The limit is needed to make sure that excessive resources are not consumed when scanning response bodies. By default, the Disable body scanner option is left unchecked, which means the response message body will be scanned for rules violations.
If response message body scanning is not disabled, traffic with response bodies larger than 512 KB are rejected.
Workaround
Disable response message body scanning by checking the Disable body scanner option when you create a WAF policy.
(MSG-6486) The WAF summary message includes 53 rules that are not supported at this time.
The WAF summary message, which appears in the RTF Input Traffic logs, lists Rule IDs for OWASP CRS that are not supported by Anypoint Security for various reasons. The correct list of rule IDs is shown in the Edge API Policies RAML file dataTypes/policies/WafRules/Rulesets.json
.
At startup, an error is thrown for each unsupported rules, however, these are not really errors.
The following Rule IDs listed in the WAF summary message are not supported:
913101, 913102, 920200, 920201, 920230, 920300, 920271, 920320, 920121,
920272, 920202, 920273, 920274, 920460, 921151, 921180, 931130, 933151,
933131, 933161, 933111, 941101, 941150, 941320, 941330, 941340, 942110,
942120, 942130, 942150, 942180, 942200, 942210, 942260, 942300, 942310,
942330, 942340, 942370, 942380, 942390, 942400, 942410, 942430, 942440,
942450, 942251, 942420, 942431, 942460, 942421, 942432, 950100
Workaround
Disregard these rule IDs in the WAF summary message report. They are always reported with zero counts. These rule IDs are not executed so there is no reason to disable them when disabling rule IDs for false positives.
(MSG-6430) In the current release, a limited non-configurable list of mime types are supported for response body checking.
The supported MIME types are:
text/plain
text/html
text/xml
application/json
If the content type of the response message does not match a supported MIME type, it is not scanned.
Workaround
If response bodies do not have a supported MIME type for response body checking, you must write additional application business logic to make appropriate checks before sending responses.
(MSG-5637) The issue where excessive logging was slowing performance for bad x-forwarded-for header
has been fixed.
The Edge was logging a message for each invalid IP address encountered in a source IP header such as x-forwarded-for
. This header is client changeable. If an attacker provided an invalid value, this log message generated at the rate of one log message for each message, which degraded Edge performance at a rate equal to how fast it could log messages.
Fix
The message was changed from ERROR level to DEBUG level so performance is not degraded for Edges that are using the recommended or default production log level setting of ERROR.