Comment concevoir et dimensionner Panorama des environnements de collecteur de journaux

La Panorama solution se compose de deux fonctions globales :
 

1. Configuration et gestion des périphériques : Cela inclut des activités telles que la gestion et le déploiement de configuration, le déploiement de pare-feux Palo Alto Networks, la mise à niveau logicielle et les mises à jour de contenu.

2. Collection de journaux: Cela comprend la collecte de journaux à partir d’un ou plusieurs pare-feu, soit à un seul Panorama ou à une infrastructure de collecte de journaux distribués. En plus de recueillir des journaux à partir de pare-feu déployés, les rapports peuvent être générés en fonction de ces données de journal, qu’elles résident localement Panorama dans la (par exemple une M- seule série ou un seul VM appareil) pour une infrastructure d’enregistrement distribuée.

La Panorama solution permet une flexibilité dans la conception en attribuant ces fonctions à différents éléments physiques de l’infrastructure de gestion. Par exemple: La gestion de l’appareil peut être effectuée à partir d’un VM Panorama , tandis que les pare-feu transmettre leurs journaux à des collecteurs de journaux dédiés collocated:

 

Dans l’exemple ci-dessus, la fonction de gestion de l’appareil et les rapports sont effectués sur VM Panorama un appareil. Il y a trois groupes de collectionneurs de journal. Groupe A , contient deux collecteurs de journaux et reçoit des journaux de trois pare-feu autonomes. Groupe B , se compose d’un seul collecteur et reçoit des journaux à partir d’une paire de pare-feu dans une haute disponibilité active / passive ( ) HA configuration. Groupe C contient deux collecteurs de journaux ainsi, et reçoit des journaux de deux HA paires de pare-feu. Le nombre de capteurs de journal dans un lieu donné dépend de plusieurs facteurs. Les considérations de conception sont traitées ci-dessous. Remarque : n’importe quelle plate-forme peut être une plate-forme uniquement de gestion et agir en tant que bûcheron, VM y compris M- et série.

• Tout physique ou virtuel qui Panorama prend en charge la fonction Log Collection.
• PAN-OS 8.1 et au-dessus

Périphériques gérés

de collection de journaux

Bien que toutes les plates-formes actuelles aient une limite supérieure de Panorama 5 000 appareils à des fins de gestion (5 000 pare-feu à l’aide M-600 PAN-OS d’un seul ou depuis 9,0), il est important pour le dimensionnement de comprendre quel sera le taux de journal entrant Panorama de tous les appareils gérés. Pour commencer, faites un inventaire de l’ensemble firewall des appareils qui seront gérés par Panorama .
 
Utilisez le tableau suivant à titre d’exemple pour faire l’inventaire de vos appareils qui doivent transmettre des journaux :

Consultez l’article suivant sur la façon de déterminer le taux de journal : Comment déterminer le taux de journal sur les périphériques ayant des exigences Panorama d’enregistrement des



collecteurs de journaux

Cette section couvrira les informations nécessaires pour tailler et déployer correctement Panorama l’infrastructure d’enregistrement pour répondre aux besoins des clients. Il y a trois principaux facteurs pour déterminer le volume de stockage total requis et comment répartir ce stockage par l’intermédiaire de collecteurs de journaux distribués. Ces facteurs sont :

1. Conditions d’ingestion de journal : Il s’agit du nombre total de journaux qui seront envoyés par seconde à Panorama l’infrastructure.

2. Exigences en matière de stockage de journaux : C’est le délai pour lequel le client doit conserver les journaux sur la plate-forme de gestion. Il y a différents facteurs de conduite pour cela, y compris les policy facteurs de motivation fondés et réglementaires en matière de conformité.

3. Emplacement de l’appareil: L’emplacement physique des pare-feu peut conduire la décision de placer les DLC appareils à des endroits éloignés en fonction de la bande WAN passante, etc.

Chacun de ces facteurs est discuté dans les sections ci-dessous :

Exigences d’ingestion
de journal Le taux agrégé de réédage du journal pour les périphériques gérés doit être compris afin d’éviter une conception où plus de journaux sont régulièrement envoyés qu’il ne peut
Panorama recevoir, traiter et écrire sur disque.  Le tableau ci-dessous décrit le nombre maximum de journaux par seconde que chaque hardware plate-forme peut transmettre Panorama et peut être utilisé lors de la conception d’une solution pour calculer le nombre maximum de journaux qui peuvent être transmis Panorama dans l’environnement client.

Limites de filage des périphériques

Le taux d’ingestion de journal Panorama est influencé par la plate-forme et le mode d’utilisation (mode mixte vs mode enregistreur). Le tableau ci-dessous montre les taux d’ingestion Panorama pour les différentes plates-formes et modes de fonctionnement disponibles. Les nombres entre parenthèses à côté VM de désigner le nombre de processeurs et gigaoctets de RAM attribués à la VM .


Panorama Taux d’ingestion de journaux pris en charge

Les chiffres ci-dessus sont toutes les valeurs maximales. Dans les déploiements de direct, le taux de journal proprement est généralement une fraction de la valeur maximale prise en charge. Détermination du taux réel journal est fortement tributaire de la composition du trafic du client et n’est pas nécessairement liée au débit. Par exemple, une seule session déchargée SMB affichera un débit élevé, mais ne générera qu’un seul journal de trafic. Inversement, vous pouvez avoir un débit plus petit composé de milliers de UDP DNS requêtes qui génèrent chacune un journal de trafic distinct. Pour le dimensionnement, une corrélation approximative peut être établie entre les connexions par seconde et les journaux par seconde.

*Sur les Panorama VMs, des capacités supplémentaires peuvent être réalisées avec plus d’allocations de ressources. Veuillez consulter les conditions préalables à la configuration de l’appareil Panorama virtuel pour plus d’informations.

Méthodes pour déterminer le taux de journal

de nouveauxclients:

• Exploiter les informations provenant de sources de client existant. De nombreux clients ont mis en place une solution d’enregistrement tierce comme Splunk, ArcSight, Qradar, etc. Le nombre de journaux envoyés à partir de leur firewall solution existante peut être retiré de ces systèmes. Lorsque vous utilisez cette méthode, obtenez un compte de journal de la solution tierce pour une journée complète et divisez par 86 400 (nombre de secondes par jour). Cela pendant plusieurs jours pour obtenir une moyenne. Assurez-vous d’inclure à la fois les jours ouvrables et non ouvrables car il ya généralement une grande variance dans le taux de journal entre les deux..

• Utilisez les données des appareils d’évaluation. Cette information peut fournir un point de départ très utile pour des fins de dimensionnement et, avec l’apport de la clientèle, les données peuvent être extrapolées pour d’autres sites dans la même conception. Cette méthode a l’avantage de donner une moyenne sur plusieurs jours. A script (avec instructions) pour aider à calculer ces informations peuvent être trouvés est joint à ce document. Pour l’utiliser, téléchargez le fichier nommé « ts_lps.zip » à partir de documents design log-collector.rar. Déballez le fichier zip et référez le README .txt pour les instructions.

• Si aucune information n’est disponible, utilisez la table de forwarding de journal d’appareil ci-dessus comme point de référence. Ce sera la méthode la moins précise pour un client particulier.

Clients existants :

Pour les clients existants, nous pouvons tirer parti des données recueillies à partir de leurs pare-feu existants et collecteurs de journaux :

• Pour vérifier le taux de journal firewall d’un seul, télécharger le fichier nommé « Device.zip » de Design Log-Collector Documents.rar, déballer le fichier zip et README référencer le fichier .txt pour les instructions. Ce paquet interrogera un seul sur firewall une période de temps spécifiée (vous pouvez choisir combien d’échantillons) et donnera un nombre moyen de journaux par seconde pour cette période. Au minimum, ce script doit être exécuté pendant 24 heures consécutives par jour ouvrable. L'exécution du script pendant une semaine complète aidera à capturer le reflux cyclique et le flux du réseau. Si le client n’a pas de collecteur de journaux, ce processus devra être exécuté contre chacun firewall dans l’environnement.

• Si le client dispose d’un collecteur de journaux (ou de collecteurs de journaux), téléchargez le fichier nommé « lc_lps.zip » de Design Log-Collector Documents.rar,déballez le fichier zip et README référez le fichier .txt pour les instructions Ce paquet interrogera le collecteur de journaux pour prendre un échantillon du taux MIB de journal entrant sur une période déterminée.

Facteurs d’exigences de stockage
 

de journal affectant les besoins de stockage de journal :

Il y a plusieurs facteurs qui conduisent des conditions de stockage de journal. La plupart de ces exigences est de nature réglementaire. Les clients peuvent avoir besoin de répondre aux exigences de HIPAA conformité pour , ou PCI Sarbanes-Oxley.

• PCI DSS exigence 10,7
• Loi Sarbanes-Oxley, section 802
• HIPAA - § 164.316(b)(2)(i)

Il existe d’autres normes gouvernementales et de l’industrie qu’il faudra considérer. En outre, certaines entreprises ont des besoins internes. Par exemple : un certain nombre de jours une valeur de journaux une note sur la plate-forme de gestion originale. Veiller à ce que toutes ces conditions sont adressés par le client lors de la conception d’une solution de stockage de journal.
 
L’accent est mis sur le nombre minimum de jours de journaux qui doivent être stockés. S’il y a un nombre maximum de jours requis (en raison de la réglementation policy ou), vous pouvez définir le nombre maximum de jours pour conserver les journaux dans la configuration des quotas.
 

Calcul du stockage requis :

Le calcul de l’espace de stockage requis en fonction des besoins d’un client donné est un processus assez simple, mais peut être à forte intensité de main-d’œuvre lors de l’obtention de degrés plus élevés de précision. Avec PAN-OS 9,1, la taille moyenne pour tous les types de grumes est de 489 Octets*. Ce nombre représente la taille totale du journal stockée sur le disque. 
 
* La taille moyenne du journal peut varier en fonction du mélange trafic/journalisation et des fonctionnalités activées.

Notez que nous ne sommes peut-être pas la solution d’enregistrement pour les archives à long terme. Dans ces cas, il suggère que Syslog soit transmis à des fins archivistiques. 

L’équation pour déterminer les exigences de stockage pour un type de journal particulier :

Exemple : Le client souhaite pouvoir garder 30 jours de grumes de trafic avec un taux de journal de 1500 billes par seconde :

Le résultat du calcul ci-dessus ne représente que les journaux détaillés ElasticSearch. Avec les paramètres de quota par défaut, réservez 60% du stockage disponible pour les journaux détaillés. Cela signifie que le nombre calculé représente 60% du stockage utilisé par ElasticSearch. Pour calculer le stockage total requis pour ElasticSearch, divisez ce nombre par 0,60 :

Un tiers (~33%) de l’espace disque disponible est alloué aux journaux formatés déconnectés. Les journaux formatés déconnectés sont stockés pour prendre en charge la mise à niveau, le déclassement et pour prendre en charge la correction de la corruption des bases de données. Pour calculer le stockage total qui devra être acheté, divisez le stockage requis pour ElasticSearch par 0,66 : quotas de journal par défaut

Panorama pour 8,0

et plus tard : Log Type % Stockage
Journaux Firewall détaillés 60
Journaux Firewall sommaires 30 Infrastructure et journaux
d’audit 5
Journaux de plate-forme Palo Alto Networks .1
journaux externes tiers .1 Veuillez consulter l’article

ci-dessous en savoir plus sur l’allocation d’espace sur : Comment Panorama l’espace disque est alloué sur les

collecteurs de journaux

En outre, la feuille de travail ci-jointe prendra en compte le quota par défaut et fournira la quantité totale de stockage Panorama requise.



Disponibilité du journal

Il existe deux méthodes de redondance pour les journaux lors de l’utilisation d’une infrastructure de collecte de journaux (dédiée ou en mode mixte).
 

Redondance du journal :

PAN-OS 8.1 et inclure plus tard une option explicite pour écrire chaque journal à 2 collecteurs de journaux dans le groupe collecteur de journaux. En activant cette option, un périphérique envoie son journal à son collecteur de journaux principal, qui reproduit ensuite le journal à un autre collecteur dans le même groupe : la duplication du journal garantit qu’il y a deux copies d’un journal donné dans le




groupe collecteur de journaux. Il s’agit d’une bonne option pour les clients qui ont besoin de garantir la disponibilité de journal à tout moment. Choses à considérer :

1. La réplication ne prend place au sein d’un groupe de collecteurs de journal.

2. L’espace de stockage total disponible est réduit de moitié (car chaque journal est écrit deux fois).

3. Taux d’ingestion de journal sera globalement réduit jusqu'à 50 %.

4. La latence devrait être <10ms between the multiple LCs within the same collector group  to avoid an Inter- LC un problème.

 
  
Liste de préférences des groupes de collectionneurs :

La méthode consiste à placer plusieurs collecteurs de journaux dans un groupe. Dans ce scénario, le firewall peut être configuré avec une liste de préférences, donc si le collecteur de journal principal descend, le deuxième collecteur de la liste recevra et stockera les journaux.

La meilleure pratique pour l’adage vers les collecteurs de journaux est d’avoir une liste de préférences de collecteur de journaux. 

Pour plus d’informations s’il vous plaît se référer à mises en garde pour un groupe de collectionneurs avec plusieurs collecteurs de journaux.

Dans l’architecture Firewall A ci-dessous, et Firewall B sont configurés pour envoyer leurs journaux à Log Collector 1 principalement, avec Log Collector 2 comme une sauvegarde. Si Log Collector 1 devient inaccessible, les périphériques enverront leurs journaux à Log Collector 2.






Considérations pour la conception du Groupe de collecteurs de
 
journaux Il y a trois raisons principales pour configurer les collecteurs de journaux dans un groupe :
 

1. Une plus grande rétention du journal est nécessaire pour un firewall ensemble spécifique (ou un ensemble de pare-feu) que ne peut être fourni par un seul collecteur de journaux (pour la conservation de l’échelle).

2. Une plus grande capacité d’ingestion est nécessaire pour un spécifique firewall que peut être fourni par un collecteur de journal unique (pour mettre à l’échelle l’ingestion).

3. Exigence de redondance du journal.

 

Lorsque l’on examine l’utilisation de groupes de collecteurs de grumes, il y a quelques considérations qui doivent être abordées à l’étape de la conception :
 

1. Répartir l’ingestion entre les collecteurs disponibles : plusieurs listes de préférences de transmettation d’appareils peuvent être créées. Cela permet à l'ingestion d'être manipulé par plusieurs collecteurs dans le groupe de collecteur. Par exemple, la liste de préférences 1 aura la moitié des pare-feu et le collecteur de liste 1 comme principal et le collecteur 2 comme secondaire. La liste de préférences 2 aura le reste des pare-feu et le collecteur de liste 2 comme principal et le collecteur 1 comme secondaire.

2. Problèmes de latence: la latence du réseau entre les collecteurs d'un groupe de collecteurs de journaux est un facteur important dans la performance. A la ligne directrice générale de conception est de garder tous les collecteurs qui sont membres du même groupe proches l’un de l’autre. Le tableau suivant donne une idée de ce à quoi vous pouvez vous attendre à différentes mesures de latence avec redondance activée et désactivée. Dans ce cas, « Log Delay » est le résultat non souhaité de la latence élevée - les journaux ne s’affichent pas dans le UI jusqu’à ce que bien après qu’ils sont envoyés à Panorama .

NOTE: La latence devrait être <10ms between the multiple LCs within the same collector group  to avoid an Inter- LC un problème. 


 
À l’aide de la feuille de calcul de dimensionnement :

Les informations dont vous aurez besoin incluent la période de rétention souhaitée et le taux de journal moyen.



Période de rétention : Nombre de jours pendant que les journaux doivent être conservés.

Tarif journal moyen: Le taux de journal agrégé mesuré ou estimé.

Redondance requise : Cochez cette case si la redondance du journal est nécessaire.

Stockage pour les journaux détaillés : La quantité de stockage (en Gigaoctets) requise pour respecter la période de conservation des journaux détaillés.

Stockage total requis : Le stockage (en Gigaoctets) à acheter. Cela représente tous les types de journaux dans les paramètres de quota par défaut.



EXAMPLE USE CASES









 

• Si vous avez des questions supplémentaires ou avez besoin d’aide pour concevoir et déployer votre environnement d’enregistrement, veuillez contacter l’équipe de compte.

• Les documents mentionnés sont zippés et joints à cet article sous le nom de Design Log-Collector Documents , disponible en téléchargement.

• Veuillez consulter le document suivant sur la façon de vérifier la configuration de la liste de préférences sur les NGFW pare-feu. Vérifier l’adage de journal à Panorama

• Veuillez consulter le document suivant sur la façon de configurer l’adage de journal