L' Pare-feu d'application Web (WAF) est un outil essentiel pour identifier et prévenir le trafic HTTP malveillant au sein des fermes HTTP(S). Il analyse les modèles de trafic et applique des politiques de sécurité avancées grâce à des ensembles organisés de règles appliquées à ces fermes. Après avoir déchiffré les paquets SSL, le WAF examine les règles, lui permettant d'appliquer des modèles au corps HTTP au sein du trafic SSL.

L' RELIANOID IPDS le forfait comprend le Ensemble de règles de base OWASP ModSecurity, qui est préchargé et prêt à l’emploi. Les utilisateurs ont également la possibilité de créer des ensembles de règles personnalisés pour une protection complète du système contre diverses attaques. Pour plus de détails sur les règles OWASP, reportez-vous au projet OWASP ModSecurity. De plus, le RELIANOID Le module WAF étend ses fonctionnalités au-delà de la protection HTTP pour inclure gestion avancée du contenu HTTP fonctionnalités, telles que les redirections et les réécritures.

Vue des ensembles de règles WAF #

La vue Ensembles de règles WAF fournit une présentation des ensembles de règles disponibles et des services de batterie qui leur sont attribués :

Nom. Un identifiant descriptif pour un ensemble de règles. Cliquez pour accéder au formulaire d'édition.
Fermes. Les exploitations agricoles auxquelles la règle s'applique. Développez la liste des fermes à l'aide de la flèche vers le haut à côté du FERMES en-tête de colonne. Limité à 20 caractères par défaut.
. Le statut de l'ensemble de règles, indiqué par des codes couleurs :

• Vert. Les utilisateurs de l’app Smart Spaces avec Google Wallet profitent d’un accès mobile sans contact avec tout lecteur HID® Signo™ compatible NFC.. L'ensemble de règles est actif et est en cours de vérification pour les fermes attribuées.
• Rouge. Hors Ligne. L'ensemble de règles est inactif et n'affecte pas les fermes.

Action. Actions disponibles pour l'état de l'ensemble de règles WAF :

• Modifier. Modifiez les paramètres de l'ensemble de règles ou affectez un service de batterie de serveurs si nécessaire.
• Recommencer. Réinitialiser une règle WAF.
• Commencer. Appliquez le jeu de règles WAF.
• Supprimer . Supprimez un ensemble de règles.

Comprendre le système de règles OWASP CRS #

L' OWASP CRS Les ensembles de règles comprennent des règles génériques de détection des attaques, offrant un niveau de protection fondamental pour toute application Web.

Modes de fonctionnement #

Les ensembles de règles préchargés OWASP CRS fonctionnent selon deux modes :

Mode de notation des anomalies (par défaut) : ce mode est recommandé pour ses informations de journal précises et ses politiques de blocage flexibles. Également connu sous le nom de « mode de détection collaboratif », il attribue un « score d'anomalie » à chaque règle de correspondance. À la fin des évaluations des règles entrantes et sortantes, le score d'anomalie déclenche des actions de blocage, entraînant généralement une erreur 403 par défaut.

Mode autonome: Ce mode applique les actions instantanément. Tout en réduisant l'utilisation des ressources, cela sacrifie la flexibilité des politiques de blocage et des journaux d'audit détaillés (seule la première menace détectée est enregistrée). Les règles suivent l'action perturbatrice que vous spécifiez (par exemple, refuser, abandonner). La première règle de correspondance exécute cette action, conduisant souvent à l'arrêt de l'évaluation après la correspondance initiale, comme c'est le cas pour de nombreux IDS.

Ensembles de règles de base OWASP CRS #

Ces règles de protection préchargées sont organisées en fonction des préférences. Si vous choisissez de les utiliser, veuillez les considérer et les appliquer de la manière suivante :

DEMANDE-90-CONFIGURATION DEMANDE-901-INITIALISATION
# Appliquez tout autre ensemble de règles OWASP en fonction de ce que vous souhaitez protéger
DEMANDE-949-RÉPONSE D'ÉVALUATION DE BLOCAGE-959-RÉPONSE D'ÉVALUATION DE BLOCAGE-980-CORRÉLATION # à des fins de journalisation, activez-le uniquement à des fins de dépannage.

Au sein de l'ensemble de règles de base de l'OWASP, le DEMANDE-INITIALISATION 901 L'ensemble de règles sert d'élément fondamental, offrant une large gamme d'options pour configurer le comportement global des règles de sécurité. Il offre aux utilisateurs la possibilité d'affiner les paramètres pour les aligner sur des besoins de sécurité spécifiques, constituant ainsi l'épine dorsale du processus de configuration des règles. Déménager DEMANDE-949-BLOCAGE-ÉVALUATION RÉPONSE-959-BLOCAGE-ÉVALUATION ensembles de règles, ceux-ci jouent un rôle essentiel dans la posture de sécurité proactive en évaluant et en exécutant des actions de blocage en fonction des scores d'anomalies. Ils contribuent de manière significative à la capacité de l'ensemble de règles de base de l'OWASP à identifier et prévenir les menaces potentielles en temps réel. En complément de ceux-ci, RÉPONSE-980-CORRÉLATION L'ensemble de règles se concentre sur la corrélation et l'analyse des réponses, améliorant ainsi la capacité globale de l'ensemble de règles de base de l'OWASP à détecter et à répondre efficacement aux défis de sécurité en constante évolution. Ensemble, ces ensembles de règles permettent aux utilisateurs de mettre en œuvre un cadre de sécurité robuste et adaptable pour leurs applications Web.

Comprendre les niveaux de paranoïa, l'échantillonnage et le score d'anomalie #

Le paramètre Paranoïa Level vous permet de spécifier l’intensité des vérifications des règles, influençant les scores d’anomalies. Des niveaux de paranoïa plus élevés améliorent la sécurité en permettant davantage de règles, mais peuvent augmenter le risque de blocage du trafic légitime en raison de faux positifs. Recommandations pour chaque niveau :

Paranoïa niveau 1 (par défaut) : convient aux débutants, aux installations diverses et aux configurations de sécurité standard, avec de rares faux positifs.
Paranoïa niveau 2: Recommandé pour les utilisateurs modérés à expérimentés recherchant une couverture complète et une sécurité renforcée. Attendez-vous à des faux positifs.
Paranoïa niveau 3: Destiné aux utilisateurs expérimentés manipulant des faux positifs, pour des installations ayant des besoins de sécurité élevés.
Paranoïa niveau 4: Conseillé aux utilisateurs expérimentés protégeant des installations avec des exigences de sécurité très élevées, mais susceptibles de produire un nombre élevé de faux positifs nécessitant une résolution avant la mise en service.

Pour élever le bloquer le niveau de paranoïa, naviguez jusqu'à DEMANDE-INITIALISATION 901 Ensemble de règles, alors Editer en mode brut et modifier l'ID de la règle 901120. Remplacer setvar:'tx.blocking_paranoia_level=1' avec votre niveau préféré.

En employant le niveau de paranoïa de détection, on peut exécuter des règles à partir d'un niveau de paranoïa plus élevé sans les prendre en compte dans la notation des anomalies. Cette flexibilité permet d'incorporer des règles du niveau de paranoïa 2 dans un système finement réglé au niveau de paranoïa 1, atténuant ainsi les inquiétudes concernant les faux positifs potentiels qui pourraient faire grimper le score au-delà du seuil établi. Par défaut, le niveau de paranoïa de détection s'aligne sur le niveau de paranoïa de blocage. Pour augmenter le niveau de paranoïa de détection, naviguez jusqu'à DEMANDE-INITIALISATION 901 Ensemble de règles, alors Editer en mode brut et modifier l'ID de la règle 901125. Remplacer setvar:'tx.detection_paranoia_level=%{TX.blocking_paranoia_level}' avec votre niveau préféré (ex. setvar:'tx.detection_paranoia_level=2').

Chaque règle du CRS se voit attribuer un niveau de gravité, avec par défaut marquer des points indiquant l'impact sur le score d'anomalie lorsqu'une règle correspond. Les niveaux de gravité et leurs scores correspondants sont les suivants :

CRITIQUE: Anomaly Score de 5, provenant principalement des règles d'attaque des applications (fichiers 93x et 94x).
ERREUR: Anomaly Score de 4, généré majoritairement par des règles de fuite sortantes (fichiers 95x).
ATTENTION: Anomaly Score de 3, principalement déclenché par des règles clients malveillantes (91x fichiers).
AVIS: Anomaly Score de 2, résultant principalement des règles protocolaires (fichiers 92x).

In mode anomalie, ces scores s'accumulent, permettant à une seule requête de déclencher plusieurs règles. Les ajustements de ces points par défaut sont généralement inutiles mais peuvent être personnalisés en fonction d'exigences spécifiques.

On peut définir le score d'anomalie cumulé à laquelle un demande entrante or réponse sortante sera bloqué. Par défaut, la plupart des menaces entrantes détectées reçoivent un score critique de 5, tandis que les violations plus petites obtiennent des scores plus faibles. Aux seuils de blocage par défaut, le CRS se comporte de la même manière que les versions précédentes, bloquant et enregistrant les demandes avec une seule correspondance de règle critique. L'ajustement des seuils de blocage à des valeurs plus élevées, telles que 7 ou 10, peut rendre le CRS moins sensible, nécessitant plusieurs correspondances de règles avant le blocage. Toutefois, la prudence est de mise, car l'augmentation des seuils peut permettre à certaines attaques de contourner les règles ou politiques. Alternativement, une stratégie de déploiement recommandée consiste à définir initialement des seuils de score d'anomalie élevés (> 100) et à les réduire progressivement à mesure que la confiance dans le système augmente, offrant ainsi une approche proactive pour améliorer la sécurité au fil du temps.

Par défaut, le seuil de score d'anomalie entrante est défini sur 5 et le seuil de score d'anomalie sortante est défini sur 4. Pour modifier le seuil de score d'anomalie entrante, naviguez jusqu'à DEMANDE-INITIALISATION 901 Ensemble de règles, alors Editer en mode brut et modifier l'ID de la règle 901100. Remplacer setvar:'tx.inbound_anomaly_score_threshold=5' avec votre niveau préféré (ex. setvar:'tx.inbound_anomaly_score_threshold=4'). De la même manière pour le seuil de score d'anomalie sortant avec l'ID de la règle 901110 remplaçant setvar:'tx.outbound_anomaly_score_threshold=4'.

L' Blocage du mode de notation précoce des anomalies permet une évaluation précoce des scores d'anomalies de demande et de réponse à la fin de la phase : 1 et de la phase : 3, respectivement, au lieu d'attendre la fin de la phase : 2 et de la phase : 4. L'activation de ce mode permet un blocage immédiat si le seuil d'anomalie est atteint lors de l'évaluation précoce, contournant ainsi l'exécution de la phase 2 (et de la phase 4, respectivement). Pour activer le blocage anticipé, activez l'ID de règle 901115 dans les DEMANDE-INITIALISATION 901 ensemble de règles, qui définit la variable tx.early_blocking à 1 (désactivé par défaut). Il est crucial de noter qu'un blocage précoce peut masquer des alertes potentielles, car les charges utiles déclenchant les alertes de phase 2 (ou phase 4) ne seront pas évaluées si le blocage anticipé est engagé. La désactivation du blocage anticipé à l'avenir pourrait révéler de nouvelles alertes de la phase 2.

L' Assouplissement / Pourcentage d’échantillonnage La fonctionnalité est conçue pour atténuer les problèmes potentiels lors de l'intégration du CRS dans un site actif existant, tels que les faux positifs et les impacts inattendus sur les performances. Pour introduire prudemment le CRS, vous pouvez l’activer dans un premier temps pour un nombre limité de requêtes. Une fois les problèmes résolus et la confiance dans la configuration établie, vous pouvez augmenter progressivement le ratio de requêtes soumises à l'ensemble de règles. Ajustez le pourcentage de demandes traitées par les règles de base en définissant tx.sampling_percentage à l'ID de règle 901130 dans les DEMANDE-INITIALISATION 901 ensemble de règles ; la valeur par défaut est 100, ce qui signifie que chaque demande est soumise aux contrôles CRS. La sélection des requêtes vérifiées est basée sur un nombre pseudo-aléatoire généré par ModSecurity. Si une demande est autorisée sans vérification CRS, elle n'aura pas d'entrée dans le journal d'audit pour des raisons de performances, mais une entrée du journal d'erreurs est enregistrée. Pour désactiver l'entrée du journal des erreurs, émettez la directive spécifiée après avoir inclus le CRS.