Comment fonctionne Azure Web Application Firewall
Vous connaissez les fonctionnalités de base et les avantages d’Azure Web Application Firewall. Vous allez découvrir à présent comment il fonctionne. Vous verrez en particulier comment des fonctionnalités telles que les ensembles de règles et les groupes de règles permettent à Azure Web Application Firewall de protéger les applications web contre les codes malveillants exploitant une faille de sécurité courants. Ces informations vous aident à déterminer si Azure Web Application Firewall est la bonne solution pour votre entreprise.
Options de déploiement
Vous pouvez déployer Azure Web Application Firewall dans le cadre d’une solution front-end Azure pour vos applications web. Vous allez commencer par créer une stratégie Azure Web Application Firewall qui comprend les paramètres suivants :
- Intégration de produits que vous souhaitez utiliser
- L’ensemble de règles managées que vous voulez utiliser
- Les éventuelles règles personnalisées à ajouter
- Le mode que vous voulez utiliser
Ensembles de règles managés par Microsoft, groupes de règles et règles
Azure Web Application Firewall contrecarre les exploits connus en appliquant des règles aux requêtes HTTP/HTTPS entrantes d’une application. Une règle est un code de pare-feu conçu pour reconnaître et empêcher une menace particulière.
Les règles utilisées par Azure Web Application Firewall pour détecter et bloquer les vulnérabilités courantes sont principalement des règles managées qui appartiennent à divers groupes de règles. Chaque groupe de règles est une collection de règles, tandis qu’un ensemble de règles managé est une collection de groupes de règles. Les ensembles de règles managés incluent les groupes de règles basés sur Microsoft Threat Intelligence, les groupes de règles CVE (Common Vulnerabilities and Exposures) et les groupes de règles de base (CRS).
Les règles CRS sont définies par OWASP (Open Web Application Security Project). L’équipe d’experts en sécurité de Microsoft code, gère et met à jour les règles managées. Vous pouvez modifier ou ajouter des règles selon les besoins. Quand une règle managée change, Microsoft met automatiquement à jour Azure Web Application Firewall sans faire subir aux applications de temps d’arrêt.
La capture d’écran suivante montre quelques règles et groupes de règles dans l’ensemble de règles par défaut Microsoft version 2.1 (DRS2.1). Cela doit vous donner une idée de l’étendue de la protection offerte par Azure Web Application Firewall.
Règles de bot
Les règles de bot identifient les mauvais bots, les bons bots et les bots inconnus en fonction de Microsoft Threat Intelligence et de règles WAF propriétaires.
Règles personnalisées
Il est possible que les règles managées offertes par Azure Web Application Firewall ne couvrent pas une menace spécifique à laquelle vos applications web sont confrontées. Dans ce cas, vous pouvez créer des règles personnalisées. Vous pouvez définir des règles personnalisées en créant des conditions qui incluent les composants suivants :
- Un type de correspondance comme l’emplacement géographique, l’adresse IP, la taille ou la chaîne
- Des variables de correspondance comme RequestHeader, QueryString, RequestUri, RequestBody, Cookies ou PostArgs
- Des méthodes de requête HTTP/HTTPS comme POST ou PUT
- Des opérateurs comme EqualContains, Regex, Begins with, Any, Ends with
- Une action comme Autoriser, Bloquer, Journaliser ou Rediriger
Géofiltrage
Par défaut, WAF répond à toutes les demandes des utilisateurs, quel que soit l’emplacement d’origine de la demande. Dans certains scénarios, vous devrez peut-être limiter l’accès à votre applications web en fonction du pays/de la région. La règle personnalisée de géofiltrage vous permet de définir un chemin spécifique sur votre point de terminaison pour autoriser ou bloquer l’accès de pays/régions spécifiés. La règle de géofiltrage utilise un code de pays/région d’intérêt à deux lettres.
Pour une règle de géofiltrage, une variable de correspondance est RemoteAddr ou SocketAddr. RemoteAddr est l’adresse IP du client d’origine qui est généralement envoyée via l’en-tête de demande X-Forwarded-For. SocketAddr est l’adresse IP source que WAF voit. Si votre utilisateur se trouve derrière un proxy, SocketAddr est souvent l’adresse du serveur proxy.
Vous pouvez combiner une condition GeoMatch et une condition de correspondance de chaîne REQUEST_URI pour créer une règle de filtrage géographique basé sur le chemin d’accès.
Restriction d’adresse IP
Les règles personnalisées d’Azure Web Application Firewall contrôlent l’accès aux applications web en spécifiant une liste d’adresses IP ou de plages d’adresses IP.
La règle personnalisée de restriction IP vous permet de contrôler l’accès à vos applications web. Pour ce faire, une adresse IP ou une plage d’adresses IP est spécifiée au format CIDR (Classless Inter-Domain Routing).
Par défaut, votre application web est accessible depuis Internet. Toutefois, vous souhaitez parfois limiter l’accès aux clients à partir d’une liste d’adresses IP connues ou de plages d’adresses IP. Pour cela, créez une règle de correspondance IP qui bloque l’accès à votre application web à partir d’adresses IP non listées dans la règle personnalisée.
Limitation du débit
Les règles personnalisées d’Azure Web Application Firewall prennent en charge la limitation de débit pour contrôler l’accès en fonction des conditions de correspondance et des débits de demandes entrantes.
Cette règle personnalisée vous permet de détecter des niveaux de trafic anormalement élevés et de bloquer certains types d’attaques par déni de service visant la couche Application. La limitation du débit vous protège également contre les clients qui ont été accidentellement mal configurés pour envoyer de grands volumes de requêtes sur une courte période. La règle personnalisée est définie par la durée de comptage de la limite de débit (intervalles d’une ou de cinq minutes) et le seuil de limite de débit (nombre maximal de demandes autorisé dans la durée de limite de débit).
Mode de détection et mode de prévention
Azure Web Application Firewall peut fonctionner dans l’un de ces deux modes. Le mode que vous choisissez dépend de la façon dont vous souhaitez que le pare-feu gère les requêtes HTTP/HTTPS entrantes qui correspondent à l’une de ses règles :
- Mode détection : consigne la demande, mais l’autorise à passer.
- Mode prévention : consigne la demande, mais ne l’autorise pas à passer.
Un scénario courant consiste à exécuter Azure Web Application Firewall en mode de détection quand vous testez une application. En mode de détection, vous pouvez rechercher deux types de problèmes :
- Faux positifs : Demandes légitimes signalées comme malveillantes par le pare-feu.
- Faux négatifs : demandes malveillantes autorisées par le pare-feu.
Quand l’application est prête à être déployée, vous passez en mode prévention.
Utilisation de Microsoft Sentinel avec Azure WAF
Azure WAF, associé à Microsoft Sentinel, peut assurer la gestion des événements relatifs aux informations de sécurité pour les ressources WAF. À l’aide de Microsoft Sentinel, vous pouvez accéder au connecteur de données WAF à Sentinel à l’aide de Log Analytics. Les classeurs WAF affichent l’analytique pour WAF sur Azure Front Door et WAF sur Application Gateway. Les règles analytiques WAF détectent les attaques SQLi et XSS à partir des journaux AFD et Application Gateway. Le notebook WAF permet d’investiguer les incidents d’injection SQL sur Azure Front Door.
