RELIANOID Pare-feu d'applications Web #
Le Pare-feu d'application Web (WAF) fonctionne comme un outil crucial pour identifier et prévenir le trafic HTTP malveillant au sein des fermes HTTP(S). En analysant les modèles, il applique des politiques de sécurité avancées sur des ensembles organisés de règles, qui sont ensuite appliquées aux fermes HTTP. Après le décryptage des paquets SSL, les règles WAF sont examinées, permettant l'application de modèles au corps HTTP au sein du trafic SSL.
Le RELIANOID IPDS le paquet intègre le Ensemble de règles de base OWASP ModSecurity, préchargé et prêt à l'emploi, tandis que les utilisateurs conservent la possibilité de créer des ensembles de règles personnalisés pour une protection complète du système contre diverses attaques. Pour explorer plus de détails sur les règles OWASP, les utilisateurs peuvent se référer au projet OWASP Modsecurity. De plus, il convient de noter que le RELIANOID Le module WAF étend ses fonctionnalités au-delà de la protection HTTP pour englober manipulation avancée du contenu HTTP, dont des redirections réécrit.
Vue des ensembles de règles WAF #
La vue Ensembles de règles WAF affiche une présentation des ensembles de règles disponibles et des services de batterie attribués :
Nom. Un nom descriptif pour identifier un ensemble de règles. Cliquez dessus pour entrer dans le formulaire d'édition.
Fermes. Les fermes auxquelles la règle s'applique. Vous pouvez développer la liste des fermes à l'aide d'une flèche vers le haut placée à côté de la FERMES en-tête de colonne à sa droite. Par défaut est limité à 20 caractères.
STATUT. L'état du jeu de règles est représenté par les codes de couleur d'état suivants:
- Vert. Moyens ACTIVÉE. L'ensemble de règles est en cours de vérification pour les fermes qui l'utilisent.
- Rouge. Moyens HANDICAPÉS. L'ensemble de règles n'est pas activé, il n'a donc aucun effet sur la batterie de serveurs.
Action. Actions autorisées pour le statut des 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 #
Le 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'.
Le 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.
Le 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.
