Comment ignorer certaines règles de paramètre dans un chemin dans ModSecurity?

J’ai fait un tas de recherches et j’ai trouvé beaucoup de pièces, mais je n’ai pas réussi à trouver quelque chose qui fera ce dont j’ai besoin. Pour commencer, je suis sur un serveur CentOS 7 exécutant ModSecurity 2.7.3.

Objectif

Je veux pouvoir parsingr tous les parameters, sauf certains, et les exécuter avec toutes les règles de base standard déjà configurées. Par exemple, si j’ai un fichier path/to/myfile.php et qu’il a 2 parameters qui lui sont envoyés param1 et param2 . Quand un utilisateur frappe myfile.php je veux qu’il exécute tous les jolis contrôles possibles contre param1 et param2 sauf avec param2 Je n’ai pas besoin de vérifier WEB_ATTACK/XSS car il devrait attendre du HTML pour ce champ (ou autre) .

Caveat

Je ne pense pas que je puisse supprimer les règles par identifiant (sauf si ma compréhension est erronée). Nous sums en train de le configurer sur un serveur de transfert, puis nous installerons ModSecurity et les exclusions que nous avons définies sur le serveur de transfert et les copions sur les serveurs actifs. Je ne pense pas que les ID de règles correspondent aux journaux lors de la mise en scène (encore une fois, sauf si je comprends mal quelque chose) et il ne serait pas amusant de lancer ModSecurity sur nos serveurs et d’attendre que les règles commencent à trébucher.

Ce que j’ai eu jusqu’ici

Voici ce que j’ai essayé …

   SecRuleEngine Off # This is super bad I know

C’est une mauvaise idée, alors je peux le faire …

   SecRuleRemoveByTag "WEB_ATTACK/XSS" # better but.....still not close enough

J’ai donc essayé sans succès les choses suivantes:

 SecRule ARGS|!ARGS:param2 "@detectXSS" # only 2.8.0 and above :( # or SecRule ARGS|!ARGS:param2 "ctl:ruleRemoveByTag=WEB_ATTACK/XSS" # or SecRule REQUEST_FILENAME "@streq /path/to/myfile.php" "pass,ctl:ruleRemoveByTag=WEB_ATTACK/XSS;ARGS:param2"

La documentation de ModSecurity est ….. bonne, mais j’ai besoin d’un peu plus de compréhension, en particulier avec ctl . J’ai aussi regardé quelques autres questions ici et ici et vu quelques articles sur le web qui m’ont aidé à prendre la bonne direction ici (très bien écrit), ici , ici et ici

Points bonus

Si je devais faire param2 et param3, devrais-je écrire 2 règles ou peuvent-elles être combinées d’une manière ou d’une autre ( ARGS:param2,param3 )?

Votre compréhension des identifiants est erronée. Les identifiants de règle doivent être identiques lors de la mise en scène et en direct – sauf si vous exécutez des règles différentes (ce qui va à l’encontre du sharepoint vue d’un serveur de transfert, sinon une vraie image de live). La plupart du temps, les utilisateurs téléchargent, achètent ou écrivent un jeu de règles avec le jeu de règles OWASP Core, un jeu de règles populaire (et gratuit!).

Il y a un exemple presque identique à ce que vous voulez faire dans la documentation ctl à laquelle vous avez lié mais avec des identifiants:

 # white-list the user parameter for rule #981260 when the REQUEST_URI is /index.php SecRule REQUEST_URI "@beginsWith /index.php" "phase:1,t:none,pass, \ nolog,ctl:ruleRemoveTargetById=981260;ARGS:user

Donc, pour vous, cela deviendrait:

 SecRule REQUEST_URI "@beginsWith /path/to/myfile.php" "id:1234,phase:2,t:none,pass, \ nolog,ctl:ruleRemoveTargetById=973336;ARGS:param2

Notez les CRS OWASP (vous ne savez pas si vous les utilisez?) Les vérifications XSS sont des vérifications de phase 2, c’est pourquoi j’ai changé cela et les identifiants sont maintenant obligatoires à partir de 2.7. Vous pouvez étendre cela pour inclure de nombreux identifiants de règle ou des arguments différents:

 SecRule REQUEST_URI "@beginsWith /path/to/myfile.php" "phase:2,t:none,pass, \ nolog,ctl:ruleRemoveTargetById=973336;ARGS:param2,\ ctl:ruleRemoveTargetById=973337;ARGS:param2,\ ctl:ruleRemoveTargetById=973338;ARGS:param2,\ ctl:ruleRemoveTargetById=973336;ARGS:param3

Cependant, il est fastidieux de définir tous les identifiants, de sorte que, comme vous vouliez le faire par tag, vous pourriez essayer ce qui devrait fonctionner mais n’a pas été testé:

 SecRule REQUEST_URI "@beginsWith /path/to/myfile.php" "id:1234,phase:2,t:none,pass, \ nolog,ctl:ruleRemoveTargetById="OWASP_CRS/WEB_ATTACK/XSS";ARGS:param2

Notez que la balise OWASP CRS est en fait "OWASP_CRS/WEB_ATTACK/XSS" plutôt que simplement "WEB_ATTACK/XSS" et ne sait pas si elle correspondra au bit partiel. .

Encore une fois, vous pouvez avoir plusieurs actions ctl sur cette ligne si vous souhaitez afficher la liste blanche param3 de la même manière.

Si cela ne fonctionne pas, vous pouvez utiliser des règles chaînées au lieu de l’action ctl:

 SecRule REQUEST_URI "@beginsWith /path/to/myfile.php" "id:1234,phase:2,t:none,pass,chain \ SecRuleUpdateTargetByTag "OWASP_CRS:WEB_ATTACK/XSS" !ARGS:param2

Cela permet de vérifier plusieurs éléments et vous donne également access à toutes les commandes de règle ModSecurity s’il n’y a pas de commande ctl équivalente (bien que ctl semble gérer la plupart des choses). Bien que ceux-ci nécessitent une règle chaînée par argument.

NOTE IMPORTANTE: La commande est importante et déroutante. SecRuleUpdateTargetByTag devrait être spécifié APRÈS les règles qu’elles modifient mais les modifications ctl doivent être spécifiées AVANT les règles qu’elles modifient.

Il convient également de noter que Location et LocationMatch ne fonctionnent pas pour les règles de phase 1 (car elles sont traitées avant qu’Apache n’exécute la logique Location et LocationMatch). Par conséquent, je préfère utiliser ModSecurity REQUEST_URI à la place. Même pour les règles de la phase 2 et ci-dessus, par souci de cohérence, elles doivent cependant fonctionner dans les sections Emplacement et EmplacementMatch.

Enfin, vous pouvez (et devriez!) Placer ModSecurity sur votre serveur live en mode DetectionOnly pour qu’il enregistre toutes les violations mais ne les bloque pas:

 SecRuleEngine DetectionOnly

Alors que vous affinez les règles, vous verrez une baisse des faux positifs jusqu’à ce que vous soyez à l’aise pour l’activer complètement.

Btw Je peux fortement recommander le manuel ModSecurity écrit par l’auteur original de ModSecurity avant de passer à autre chose. N’a pas été mis à jour depuis ModSecurity 2.6 mais, mis à part le fait qu’il devient obligatoire, tout ce qu’il couvre est toujours d’actualité et vous permettra de vérifier les notes de version de ModSecurity (dans votre installation ou ici ). voir ce qui a changé Nous vous recommandons également de passer à la dernière version (2.9.1) en tant que correctifs de bogues depuis la version 2.7.3.