403 on id 920420 for ActiveSync traffic

pittbull commented 4 years ago

Hi.

I've implemented your code and I seem to have everything in order. When I introduce it in front of my Exchange 2013 server the traffic do get blocked with the following error:

1586248130.204504 [00] [client 127.0.0.1] ModSecurity: Access denied with code 403 (phase 2). Match of "rx ^%{tx.allowed_request_content_type}$" against "TX:0" required. [file "/etc/modsecurity/owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "914"] [id "920420"] [msg "Request content type is not allowed by policy"] [data "application/vnd.ms-sync.wbxml"] [severity "CRITICAL"] [ver "OWASP_CRS/3.2.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-protocol"] [tag "OWASP_CRS"] [tag "OWASP_CRS/POLICY/CONTENT_TYPE_NOT_ALLOWED"] [tag "WASCTC/WASC-20"] [tag "OWASP_TOP_10/A1"] [tag "OWASP_AppSensor/EE2"] [tag "PCI/12.1"] [hostname "8b9ea79884c8"] [uri "http://<server>/Microsoft-Server-ActiveSync"] [unique_id ""]

I then moved on to changing my main config files (crs-setup.conf and owasp-modsecurity-crs.conf - some confusion as to which file to use) as follows:

uncommented rule 900220 and added application/vnd.ms-sync.wbxml:

SecAction \ "id:900220,\ phase:1,\ nolog,\ pass,\ t:none,\ setvar:'tx.allowed_request_content_type=application/vnd.ms-sync.wbxml|application/x-www-form-urlencoded| (setvar line capped for readability)

This does not change the behaviour and the same error is still logged and clients getting 403.

Any insights?

pittbull commented 4 years ago

Anybody?

jcmoraisjr commented 4 years ago

Hi, sorry for taking so long. This project is just a wrapper for modsecurity and we aren't that expert in the component. Perhaps you can find the real experts in the modsecurity forum/list.

GMartinez-Sisti commented 3 years ago

You can use a config file and load it as the last config file argument. The idea is that modsecurity loads all rules and in the end disables/updates the ones we want with this config. As far as I know, this is common practice so you don't mess up with the default rules files and can update them easily.

Example custom.conf:

# HTTP methods that a client is allowed to use.
# Default: GET HEAD POST OPTIONS
# Example: for RESTful APIs, add the following methods: PUT PATCH DELETE
# Example: for WebDAV, add the following methods: CHECKOUT COPY DELETE LOCK
#          MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK
SecAction \
  "id:900200,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:'tx.allowed_methods=GET HEAD POST OPTIONS PUT PATCH DELETE'"
# Disable rule 111111
SecRuleRemoveById 111111
# Add application/x-custom-ext to allowed content types
SecAction \
  "id:900220,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|application/csp-report|application/xss-auditor-report|text/plain|application/x-custom-ext'"

jcmoraisjr / modsecurity-spoa

403 on id 920420 for ActiveSync traffic #4