VxRail Manager API: Unusual and suspicious request blocked

Hello,

We have developed a java REST client using Apache HttpComponents to communicate with the VxRail manager REST API. It was working fine but since VxRail 7.0, we face to a communication issue on all requests: the server responds us with a HTTP 403 status and the message: "Unusual and suspicious request blocked. If you think this is a false positive alert, please contact support team."

The strange thing is if we use a REST client like postman or yarc, the VxRail Manager responds successfully. Anyone can help us about this security message?

Thanks.
Chris

Responses(2)

B

BrianBollard

1 Message

0

June 17th, 2022 10:00

Hi Chris,

I encountered something similar. Starting with VxRail 7.0 the Dell team added new security controls to ensure communications to the VxRail Manager are legitimate.

This module inspects incoming requests against a set of rules.

In my case, what was causing the issue was an HTTP GET Request that was setting the Content-Length value to 4. This of course doesn't make sense for a GET request so when I made the correction the HTTP calls were then accepted by the VxRail Manager.

So my advice is to examine every aspect of your REST client to ensure all calls are conforming 100% to the HTTP protocol.

Best,

Brian

C

chrisnerr

2 Posts

0

July 7th, 2022 08:00

Hello Brian,

Thanks for your reply!

We investigated the VxRail functionning and found that the appliance uses docker to run many containers and especially a Nginx server with ModSecurity + OWASP CRS.
In the Nginx long.term.log, we found that:

2022-06-24-13:24:33 microservice.api-gateway "2022/06/24 13:24:33 [error] 13880#13880: *5161521 [client 192.168.116.187] ModSecurity: Access denied with code 403 (phase 2). Matched ""Operator `Ge' with parameter `5' against variable `TX:ANOMALY_SCORE' (Value: `5' ) [file ""/etc/nginx/modsec/owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf""] [line ""80""] [id ""949110""] [rev """"] [msg ""Inbound Anomaly Score Exceeded (Total Score: 5)""] [data """"] [severity ""2""] [ver ""OWASP_CRS/3.3.0""] [maturity ""0""] [accuracy ""0""] [tag ""application-multi""] [tag ""language-multi""] [tag ""platform-multi""] [tag ""attack-generic""] [hostname ""172.28.173.8""] [uri ""/rest/vxm/v1/system""] [unique_id ""165607707344.113986""] [ref """"], client: 192.168.116.187, server: localhost, request: ""GET /rest/vxm/v1/system?null HTTP/1.1"", host: ""192.168.116.138:443"""

No other informations available about the root cause, even in the modsec_audit.log

So we decide to install a similar setup with Nginx+ and the vxrail security configuration and finally found the reason:

ModSecurity: Warning. Matched "Operator `Rx' with parameter `^utf-8|iso-8859-1|iso-8859-15|windows-1252$' against variable `TX:1' (Value: `utf8' ) [file "/etc/nginx/modsec/coreruleset-3.3.2/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "965"] [id "920480"] [rev ""] [msg "Request content type charset is not allowed by policy"] [data "utf8"] [severity "2"] [ver "OWASP_CRS/3.3.2"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/255/153"] [tag "PCI/12.1"] [hostname "10.130.34.53"] [uri "/"] [unique_id "165711243282.794103"] [ref "o18,12o26,4v29,30t:lowercase"]

Our HTTP client set the request header "content-type" to "application/json; charset=utf8" which is refused by the ModSec/CRS: "Request content type charset is not allowed by policy"...

In conclusion, you was right

View All

No Events found!