informations de référence sur les données de surveillance Pare-feu Azure

Cet article contient toutes les informations de référence de surveillance pour ce service.

Consultez surveiller Pare-feu Azure pour plus d’informations sur les données que vous pouvez collecter pour Pare-feu Azure et comment l’utiliser.

Metrics

Cette section répertorie toutes les métriques de plateforme collectées automatiquement pour App Service. Ces métriques font également partie de la liste globale de toutes les métriques de plateforme prises en charge dans Azure Monitor.

Pour plus d’informations sur les métriques de surveillance, consultez la section Présentation des métriques Azure Monitor.

Métriques prises en charge pour Microsoft.Network/azureFirewalls

Le tableau suivant répertorie les métriques disponibles pour le type de ressource Microsoft.Network/azureFirewalls.

• Toutes les colonnes peuvent ne pas être présentes dans chaque table.
• Certaines colonnes peuvent dépasser la zone d’affichage de la page. Sélectionnez Développer la table pour afficher toutes les colonnes disponibles.

En-têtes de tableau

• Catégorie : le groupe de métriques ou classification.
• Métrique : nom d’affichage de la métrique tel qu’il apparaît dans le portail Azure.
• Nom dans l’API REST : le nom de la métrique comme appelé dans l’API REST.
• Unité : unité de mesure.
• Agrégation : type d’agrégation par défaut. Valeurs valides : Moyen (moy), Minimum (min), Maximum (max), Total (somme), Nombre.
• Dimensions - Dimensions disponibles pour l'indicateur.
• Fragments de temps - Intervalles auxquels la métrique est échantillonnée. Par exemple, PT1M indique que la métrique est échantillonnée toutes les minutes, PT30M toutes les 30 minutes, PT1H toutes les heures, et ainsi de suite.
• Exportation DS : indique si la métrique est exportable vers les journaux Azure Monitor via les paramètres de diagnostic. Pour plus d’informations sur l’exportation des métriques, consultez Créer des paramètres de diagnostic dans Azure Monitor.

Capacité observée

La métrique de capacité observée est l’outil principal pour comprendre la façon dont votre pare-feu est mis à l’échelle dans la pratique.

Meilleures pratiques pour l’utilisation de la capacité observée

• Validez votre configuration de précaling : Vérifiez que votre pare-feu conserve de façon cohérente la valeur minCapacity que vous avez définie.
• Suivez le comportement de mise à l’échelle en temps réel : Utilisez l’agrégation Avg pour afficher les unités de capacité en temps réel.
• Prévoir les besoins futurs : Combinez la capacité observée historique avec les tendances du trafic (par exemple, les pics mensuels ou les événements saisonniers) pour affiner votre planification de la capacité.
• Définir des alertes proactives : Configurez des alertes Azure Monitor sur des seuils de capacité observés (par exemple, une alerte lorsque la mise à l’échelle dépasse 80% de maxCapacity).
• Mettre en corrélation avec les métriques de performances : Associez la capacité observée avec le débit, la sonde de latence et l’utilisation du port SNAT pour diagnostiquer si la mise à l’échelle continue à augmenter la demande.

État d’intégrité du pare-feu

Dans le tableau précédent, la métrique d’état d’intégrité du pare-feu a deux dimensions :

• État : Les valeurs possibles sont saines, détériorées, non saines.
• Motif : indique la raison de l’état correspondant du pare-feu.

Si les ports SNAT sont utilisés plus de 95%, ils sont considérés comme épuisés et l’intégrité est de 50% avec status=Détérioré et reason=Port SNAT. Le pare-feu continue à traiter le trafic et les connexions existantes ne sont pas affectées. Toutefois, de nouvelles connexions peuvent ne pas être établies par intermittence.

Si les ports SNAT sont utilisés à moins de 95 %, le pare-feu est considéré comme sain et l’intégrité est affichée à 100 %.

Si aucune utilisation des ports SNAT n'est signalée, l'intégrité est affichée à 0 %.

Utilisation des ports SNAT

Pour la métrique d’utilisation du port SNAT, lorsque vous ajoutez d’autres adresses IP publiques à votre pare-feu, davantage de ports SNAT sont disponibles, ce qui réduit l’utilisation des ports SNAT. En outre, lorsque le pare-feu augmente pour différentes raisons (par exemple, le processeur ou le débit) plus de ports SNAT deviennent également disponibles.

En fait, un pourcentage donné d’utilisation des ports SNAT peut diminuer sans ajouter d’adresses IP publiques, simplement parce que le service a été mis à l’échelle. Vous pouvez contrôler directement le nombre d’adresses IP publiques disponibles pour augmenter les ports disponibles sur votre pare-feu. Toutefois, vous ne pouvez pas contrôler directement la mise à l’échelle du pare-feu.

Si votre pare-feu est en cours d’épuisement des ports SNAT, vous devez ajouter au moins cinq adresses IP publiques. Cela augmente le nombre de ports SNAT disponibles. Pour plus d’informations, consultez Fonctionnalités du Pare-feu Azure.

Sonde de latence AZFW

La métrique de la sonde de latence AZFW mesure la latence globale ou moyenne du Pare-feu Azure en millisecondes. Les administrateurs peuvent se servir de cette métrique aux fins suivantes :

• Diagnostiquer si le Pare-feu Azure provoque une latence dans le réseau
• Surveiller et alerter les problèmes de latence ou de performances, afin que les équipes informatiques puissent s’engager de manière proactive
• Identifier différents facteurs pouvant entraîner une latence élevée dans le Pare-feu Azure, tels que l’utilisation élevée du processeur, le débit élevé ou les problèmes réseau

Mesures de la sonde de latence AZFW

• Dispositions: Latence du Pare-feu Azure au sein de la plateforme Azure
• Ne mesure pas : Latence de bout en bout pour l’ensemble du chemin réseau. La métrique reflète les performances au sein du pare-feu plutôt que le pare-feu Azure de latence introduit dans le réseau
• Rapport d’erreurs : Si la métrique de latence ne fonctionne pas correctement, elle signale une valeur de 0 dans le tableau de bord des métriques, indiquant une défaillance ou une interruption de la sonde

Facteurs qui ont un impact sur la latence

Plusieurs facteurs peuvent affecter la latence du pare-feu :

• Utilisation élevée du processeur
• Débit élevé ou charge du trafic
• Problèmes de mise en réseau au sein de la plateforme Azure

Sondes de latence : d’ICMP à TCP

La sonde de latence utilise actuellement la technologie Ping Mesh de Microsoft, basée sur ICMP (Internet Control Message Protocol). ICMP convient aux contrôles d’intégrité rapides, tels que les requêtes ping, mais il peut ne pas représenter avec précision le trafic d’application réel, qui s’appuie généralement sur TCP. Toutefois, les sondes ICMP hiérarchisent différemment sur la plateforme Azure, ce qui peut entraîner des variations entre les références SKU. Pour réduire ces différences, Pare-feu Azure prévoit de passer à des sondes TCP.

Considérations importantes :

• Pics de latence : Avec les sondes ICMP, les pics intermittents sont normaux et font partie du comportement standard du réseau hôte. Ne pas mal interpréter ces pics comme des problèmes de pare-feu, sauf s’ils persistent.
• Latence moyenne : En moyenne, la latence du pare-feu Azure est comprise entre 1 ms et 10 ms, selon la référence SKU et la taille de déploiement du pare-feu.

Meilleures pratiques pour la surveillance de la latence

• Définir une base de référence : établissez une ligne de base de latence dans des conditions de trafic léger pour des comparaisons précises pendant une utilisation normale ou maximale.

  Note

  Lors de l’établissement de votre base de référence, attendez-vous à des pics de métriques occasionnels en raison de modifications récentes de l’infrastructure. Ces pics temporaires sont normaux et résultent des ajustements des rapports de métriques, et non des problèmes réels. Envoyez uniquement une demande de support si les pics persistent au fil du temps.

• Surveiller les modèles : attendez des pics de latence occasionnels dans le cadre d’opérations normales. Si une latence élevée persiste au-delà de ces variations normales, cela peut indiquer un problème plus approfondi nécessitant une investigation.

• Seuil de latence recommandé : une recommandation est que la latence ne doit pas dépasser 3x la ligne de base. Si ce seuil est franchi, une enquête supplémentaire est recommandée.

• Vérifiez la limite de règle : vérifiez que les règles réseau se trouvent dans la limite de la règle 20K. Le dépassement de cette limite peut affecter les performances.

• Nouvelle intégration d’applications : recherchez toutes les applications nouvellement intégrées susceptibles d’ajouter une charge importante ou de provoquer des problèmes de latence.

• Demande de support : si vous observez une dégradation continue de la latence qui ne s’aligne pas sur le comportement attendu, envisagez de déposer un ticket de support pour obtenir une assistance supplémentaire.

  

Dimensions de métrique

Pour plus d’informations sur les dimensions de métrique, consultez Métriques multidimensionnelles.

Ce service a les dimensions suivantes associées à ses métriques.

• Protocol
• Reason
• Status

Journaux d’activité de ressources

Cette section répertorie les types de journaux d’activité de ressources que vous pouvez collecter pour ce service. La section extrait la liste de tous les types de catégorie de journaux d’activité de ressources pris en charge dans Azure Monitor.

Journaux de ressources pris en charge pour Microsoft.Network/azureFirewalls

Journaux de trace de flux DNS

Les journaux de trace de flux DNS offrent une visibilité plus approfondie de l’activité DNS, ce qui aide les administrateurs à résoudre les problèmes de résolution et à vérifier le comportement du trafic.

Auparavant, la journalisation du proxy DNS était limitée à :

• AZFWDNSQuery : requête cliente initiale
• AZFWInternalFqdnResolutionFailure - Échecs de résolution FQDN

Avec les journaux de suivi de flux DNS, les administrateurs peuvent suivre le flux de résolution DNS complet à partir de la requête du client via le Pare-feu Azure en tant que proxy DNS, vers le serveur DNS externe et revenir au client.

Étapes de résolution DNS

Les journaux capturent les étapes suivantes :

1. Requête cliente : requête DNS initiale envoyée par le client
2. Requête de redirecteur : Pare-feu Azure transférant la requête vers un serveur DNS externe (s’il n’est pas mis en cache)
3. Réponse du redirecteur : réponse du serveur DNS au Pare-feu Azure
4. Réponse du client : réponse finale résolue du Pare-feu Azure au client

Le diagramme suivant montre une représentation visuelle de haut niveau du flux de requête DNS :

Ces journaux fournissent des insights précieux, tels que :

• Le serveur DNS interrogé
• Adresses IP résolues
• Indique si le cache du pare-feu Azure a été utilisé

Activation des journaux de trace de flux DNS

Avant de configurer les journaux de trace de flux DNS, vous devez d’abord activer la fonctionnalité à l’aide d’Azure PowerShell.

Activer les journaux (prérequis)

Exécutez les commandes suivantes dans Azure PowerShell, en remplaçant les espaces réservés par vos valeurs :

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableDnstapLogging = $true
Set-AzFirewall -AzureFirewall $firewall

Désactiver les journaux (facultatif)

Pour désactiver les journaux, utilisez la même commande Azure PowerShell précédente et définissez la valeur sur False :

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableDnstapLogging = $false
Set-AzFirewall -AzureFirewall $firewall

Configurer les journaux de suivi de flux DNS et proxy DNS

Procédez comme suit pour configurer le proxy DNS et activer les journaux de trace de flux DNS :

1. Activer le proxy DNS :

   1. Accédez aux paramètres DNS du Pare-feu Azure et activez le proxy DNS.
   2. Configurez un serveur DNS personnalisé ou utilisez le DNS Azure par défaut.
   3. Accédez aux paramètres DNS du réseau virtuel et définissez l’adresse IP privée du pare-feu comme serveur DNS principal.

2. Activez les journaux de trace de flux DNS :

   1. Accédez au Pare-feu Azure dans le portail Azure.
   2. Sélectionnez Paramètres de diagnostic sous Surveillance.
   3. Choisissez un paramètre de diagnostic existant ou créez-en un.
   4. Dans la section Journal , sélectionnez Journaux de trace de flux DNS.
   5. Choisissez la destination souhaitée (Log Analytics ou compte de stockage).

   Note

   Les journaux de traces DNS Flow ne sont pas pris en charge avec Event Hub comme destination.

   6. Enregistrez les paramètres.

3. Tester la configuration :

   1. Générez des requêtes DNS à partir de clients et vérifiez les journaux dans la destination choisie.

Comprendre les journaux

Chaque entrée de journal correspond à une étape spécifique du processus de résolution DNS. Le tableau suivant décrit les types de journaux et les champs clés :

Les champs ci-dessus ne sont qu’un sous-ensemble des champs disponibles dans chaque entrée de journal.

Remarques importantes :

• Si le cache DNS est utilisé, seules les entrées Requête client et Réponse du client sont générées.
• Les journaux incluent des métadonnées standard telles que les horodatages, les adresses IP source/destination, les protocoles et le contenu du message DNS.
• Pour éviter un volume de journaux excessif dans les environnements avec de nombreuses requêtes de courte durée, activez des journaux de proxy DNS supplémentaires uniquement lorsque la résolution des problèmes DNS plus approfondie est nécessaire.

Principaux flux

Le journal des flux principaux est connu dans le secteur comme journal des flux de graisse et dans le tableau précédent comme Pare-feu Azure journal de flux de graisse. Le journal des flux principaux affiche les connexions principales qui contribuent au débit le plus élevé via le pare-feu.

Le débit de flux est défini comme le taux de transmission de données en mégabits par seconde unités. Il s’agit d’une mesure de la quantité de données numériques qui peuvent être transmises sur un réseau pendant une période de temps via le pare-feu. Le protocole Flux principaux s’exécute régulièrement toutes les trois minutes. Le seuil minimal à considérer comme un flux supérieur est de 1 Mbits/s.

Activer les journaux des flux principaux

Utilisez les commandes Azure PowerShell suivantes pour activer les journaux de flux principaux :

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableFatFlowLogging = $true
Set-AzFirewall -AzureFirewall $firewall

Désactiver les journaux des flux principaux

Pour désactiver les journaux, utilisez la même commande Azure PowerShell et définissez la valeur sur False. Par exemple:

Set-AzContext -SubscriptionName <SubscriptionName>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableFatFlowLogging = $false
Set-AzFirewall -AzureFirewall $firewall

Vérifier la configuration

Il existe plusieurs façons de vérifier que la mise à jour a réussi. Accédez à la vue d’ensemble du pare-feu et sélectionnez l’affichage JSON en haut à droite. Voici un exemple :

Pour créer un paramètre de diagnostic et activer une table spécifique à la ressource, consultez Créer des paramètres de diagnostic dans Azure Monitor.

Trace de flux

Les journaux de pare-feu affichent le trafic via le pare-feu lors de la première tentative d’une connexion TCP, appelée paquet SYN . Toutefois, une telle entrée n’affiche pas le parcours complet du paquet dans l’établissement d’une liaison TCP. Par conséquent, il est difficile de résoudre les problèmes si un paquet est supprimé ou si un routage asymétrique s’est produit. Le journal de trace de flux Pare-feu Azure répond à ce problème.

Propriétés de trace de flux

Les propriétés suivantes peuvent être ajoutées :

• SYN-ACK : indicateur ACK qui indique l’accusé de réception du paquet SYN.

• FIN : indicateur terminé du flux de paquets d’origine. Plus aucune donnée n’est transmise dans le flux TCP.

• FIN-ACK : indicateur ACK qui indique l’accusé de réception du paquet FIN.

• RST : l’indicateur de réinitialisation indique que l’expéditeur d’origine ne reçoit pas plus de données.

• INVALID (flux) : indique que le paquet ne peut pas être identifié ou n’a pas d’état.

  Par exemple:

  • Un paquet TCP atterrit sur une instance de groupe de machines virtuelles identiques, qui n'a pas d'historique pour ce paquet
  • Paquets de somme de contrôle incorrecte
  • L’entrée de la table suivi des connexions est complète et les nouvelles connexions ne peuvent pas être acceptées
  • Paquets ACK trop retardés

Activer les journaux de suivi de flux

Utilisez les commandes Azure PowerShell suivantes pour activer les journaux de trace flow. Vous pouvez également naviguer dans le portail et rechercher l’activation de la journalisation des connexions TCP :

Connect-AzAccount 
Select-AzSubscription -Subscription <subscription_id> or <subscription_name>
Register-AzProviderFeature -FeatureName AFWEnableTcpConnectionLogging -ProviderNamespace Microsoft.Network
Register-AzResourceProvider -ProviderNamespace Microsoft.Network

Cette modification peut prendre plusieurs minutes. Une fois la fonctionnalité inscrite, envisagez d’effectuer une mise à jour sur Pare-feu Azure pour que la modification prenne effet immédiatement.

Vérifier l’état de l’inscription

Pour vérifier l’état de l’inscription AzResourceProvider, exécutez la commande Azure PowerShell suivante :

Get-AzProviderFeature -FeatureName "AFWEnableTcpConnectionLogging" -ProviderNamespace "Microsoft.Network"

Désactiver les journaux de suivi de flux

Pour désactiver le journal, utilisez les commandes Azure PowerShell suivantes :

Connect-AzAccount 
Select-AzSubscription -Subscription <subscription_id> or <subscription_name>
$firewall = Get-AzFirewall -ResourceGroupName <ResourceGroupName> -Name <FirewallName>
$firewall.EnableTcpConnectionLogging = $false
Set-AzFirewall -AzureFirewall $firewall

Pour créer un paramètre de diagnostic et activer une table spécifique à la ressource, consultez Créer des paramètres de diagnostic dans Azure Monitor.

Tables Azure Monitor Logs

Cette section répertorie les tables de journaux Azure Monitor pertinentes pour ce service, disponibles pour une requête par l’analytique des journaux d’activité à l’aide de requêtes Kusto. Les tables contiennent les données du journal des ressources et éventuellement d’autres données en fonction de ce qui est collecté et acheminé vers elles.

Pare-feu Azure Microsoft.Network/azureFirewalls

• AZFWNetworkRule
• AZFWFatFlow
• AZFWFlowTrace
• AZFWApplicationRule
• AZFWThreatIntel
• AZFWNatRule
• AZFWIdpsSignature
• AZFWDnsQuery
• AZFWInternalFqdnResolutionFailure
• AZFWNetworkRuleAggregation
• AZFWApplicationRuleAggregation
• AZFWNatRuleAggregation
• AzureActivity
• AzureMetrics
• AzureDiagnostics

Journal d’activité

La table liée répertorie les opérations qui peuvent être enregistrées dans le journal d’activité de ce service. Ces opérations constituent un sous-ensemble de toutes les opérations possibles du fournisseur de ressources dans le journal d’activité.

Pour plus d’informations sur le schéma des entrées du journal d’activité, consultez Schéma du journal d’activité.

• Opérations du fournisseur de ressources réseau

Contenu connexe

• Consultez Pare-feu Azure Surveiller pour obtenir une description des Pare-feu Azure de surveillance.
• Consultez Suivre les modifications apportées aux ensembles de règles pour obtenir des requêtes Azure Resource Graph détaillées pour suivre les modifications apportées aux règles de pare-feu.
• Pour plus d’informations sur la supervision des ressources Azure, consultez Superviser des ressources Azure avec Azure Monitor.