Again about russian letters in Modsecurity rules

[valeriy-l]

Hi there!
Can you help me find out solution.
I have Modsecurity v3.0.5. and CRS 3.3.2 installed on astralinux.

I faced with many false positives on the sites with russian letters.
For example:

[data "ARGS:query=\xd0\x98\xd0\xb2\xd0\xb0\xd0\xbd\xd0\xbe\xd0\xb2 \xd0\x98\xd0\xb2\xd0\xb0\xd0\xbd \xd0\x98\xd0\xb2\xd0\xb0\xd0\xbd\xd0\xbe\xd0\xb2\xd0\xb8\xd1\x87"]

rule 920273 [msg "Invalid character in request (outside of very strict set)"]

That is Иванов Иван Иванович in russian

I have read many discussion threads here, and try solution:
change Unicode mapping to 1251, added to unicode mapping file missing strings

0410:c0 0411:c1 0412:c2 0413:c3 0414:c4 0415:c5 0416:c6 0417:c7 0418:c8 0419:c9 041a:ca 041b:cb 041c:cc 041d:cd 041e:ce 041f:cf 0420:d0 0421:d1 0422:d2 0423:d3 0424:d4 0425:d5 0426:d6 0427:d7 0428:d8 0429:d9 042a:da 042b:db 042c:dc 042d:dd 042e:de 042f:df 0430:e0 0431:e1 0432:e2 0433:e3 0434:e4 0435:e5 0436:e6 0437:e7 0438:e8 0439:e9 043a:ea 043b:eb 043c:ec 043d:ed 043e:ee 043f:ef 0440:f0 0441:f1 0442:f2 0443:f3 0444:f4 0445:f5 0446:f6 0447:f7 0448:f8 0449:f9 044a:fa 044b:fb 044c:fc 044d:fd 044e:fe 044f:ff 0401:a8 0451:b8

But I faced with false positive again and again.

What do I do wrong?

[martinhsv]

Hello @valeriy-l ,

Your question is really about the specific rule 920273 from CRS. That rule set is managed separately from the engine (this github is for the engine itself rather than for specific rules from specific rule sets). If you have questions beyond beyond what I'm about to say, you should consider inquiring at the CRS github (coreruleset).

You probably do not want to use that particular rule. Rule 920273 is a specific and strict rule meant to allow a limited set of bytes as input. Such a rule may be advantageous in some installations, but it probably is not for yours.

What you can do:

• revisit the paranoia level you are using for CRS. There is a reason that rule set has been implemented that way. More strict rules reduce the potential for attacks but also, inevitably increase the probability for false positives.
• if you like the overall set of rules you get at your current paranoia level, you could simply remove 920273 from your set using SecRuleRemoveById
• if you want to mostly retain 920273, but only eliminate the false positives that occur in specific situations you can selectively disable that rule using other ModSecurity techniques such as a) modifying the set of targets that the rule runs against (e.g. SecRuleUpdateTargetById ) or only disable the rule when particular other inputs are true (e.g. if the REQUEST_FILENAME has a particular value you could use ctl:ruleRemoveById )

As to why your attempted change does not work, there are multiple problems, including:

• The portion after the colon indicates what byte you are mapping 'to'. So, for "0410:c0", the best case scenario is that ModSecurity will see a single hex byte of 0xc0. This is not within the valid bytes that are specified in rule 920273. I.e. 920273 severely restricts what bytes are valid and 0xc0 is not one of them. On the other hand if you used the translation "0410:41", then then particular issue would be resolved (see for example Add Cyrilyc charracters to unicode.mapping #2353 )
• The translations in the unicode.mapping file need first need processing from the binary encoding. Some rules will appropriately use t:utf8toUnicode and t:urlDecodeUni in concert. There are some CRS rules that do this but 920273 does not.

[valeriy-l]

Thank you for the answer. Unfortunately, I have the same problem with rule 942460. But both rules are from REQUEST-920-PROTOCOL-ENFORCEMENT and it is common problem with them?

[martinhsv]

Hi @valeriy-l ,

Questions that are about specific rules in particular a ruleset are best directed to the ruleset maintainers.