Decoder : Configurer la fonction 10G

Document created by RSA Information Design and Development Employee on Apr 28, 2019
Version 1Show Document
  • View in full screen mode
 

Destinée aux administrateurs, cette rubrique explique comment configurer un Network Decoder spécifiquement pour capturer des paquets à vitesse élevée à l'aide de NetWitness Platform 11.x. Elle traite de la capture de paquets sur une carte d’interface 10G. La capture de paquets à vitesse élevée nécessite une configuration minutieuse et pousse le matériel du Decoder jusqu’à ses dernières limites. Aussi, lisez attentivement cette rubrique lorsque vous mettez en œuvre une solution de capture 10G.

RSA NetWitness Platform permet d’effectuer une collecte à grande vitesse sur le Decoder. Vous pouvez capturer des données de paquets réseau issues de réseaux de vitesse supérieure et optimiser votre Network Decoder pour capturer le trafic réseau pouvant atteindre 8 Gbits/s en débit soutenu et 10 Gbits/s lors d'un pic de charge, en fonction des parsers et des flux que vous avez activés.

Voici les améliorations apportées pour faciliter la fonctionnalité de capture dans ces environnements :

  • Utilisation de la fonctionnalité du pilote de capture pf_ring afin d’exploiter les atouts de la carte réseau 10G Intel pour obtenir des captures à grande vitesse.
  • Introduction de la configuration assembler.parse.valve, qui désactive automatiquement les analyseurs d’application lorsque certains seuils sont dépassés, afin de limiter les risques de perte de paquets. Lorsque les analyseurs d’application sont désactivés, les analyseurs de la couche réseau restent actifs. Lorsque les statistiques chutent sous les seuils dépassés, les analyseurs d’application sont automatiquement réactivés.

Matériel requis

  • Decoder de la gamme 4S ou 5
  • Carte Ethernet basée sur Intel 82599, comme Intel x520. Toutes les cartes RSA 10G fournies répondent à ces exigences. Voici deux exemples :
    • Toutes les cartes SMC-10GE fournies par RSA.
    • Une carte réseau fille de Dell utilisant un contrôleur Intel pour fournir des interfaces réseau 10G. Elle est incluse dans tout le matériel de la gamme 5.
  • Pour la gamme 4S / Dell R620 uniquement : 96 Go de mémoire DD3-1600 sous forme de modules DIMM à double rangée. Les modules DIMM à simple rangée peuvent réduire les performances à hauteur de 10 %. Pour déterminer la vitesse et le nombre de rangées des modules DIMM installés, exécutez cette commande :
    dmidecode -t 17.
  • Espace de stockage suffisamment volumineux et rapide pour répondre aux besoins de capture. Les considérations relatives au stockage sont abordées plus loin dans cette rubrique.
  • Chaque Network Decoder doit être configuré avec un minimum de 2 DAC ou une connectivité SAN.

Logiciels requis

  • Les systèmes Dell R620 tels que la gamme 4S doivent subir une mise à jour de leur BIOS vers la version 1.2.6 ou supérieure.
  • La fonction 10G Decoder est uniquement prise en charge sur les images d’installation du Decoder fournies par RSA. Tout logiciel requis est installé par défaut.
  • Si vous procédez à la mise à niveau depuis une version précédente, effectuez d’abord la mise à niveau avant de procéder à la configuration.

Installer le 10G Decoder

Remarque : vous pouvez ignorer l’étape « Configurer le 10G Decoder » si vous démarrez avec le nouveau matériel de la gamme 5.

Pour installer NetWitness 10G Decoder, procédez comme suit :

Téléchargez et mettez à jour le BIOS

Remarque : les révisions du BIOS antérieures à la version 1.2.6 peinent à identifier correctement l’emplacement de la carte de capture 10G au sein du système. Il est recommandé que les clients effectuent une mise à jour vers le tout-dernier BIOS v2.2.3, mais il n’est pas nécessaire pour 10G s’ils exécutent la version 1.2.6 ou ultérieure.

  1. Téléchargez le BIOS v2.2.3 depuis le lien suivant :

    http://www.dell.com/support/home/us/en/19/Drivers/DriversDetails?driverId=V7P04

  2. Téléchargez le package de mise à jour du fichier Red Hat Linux.
  3. Copiez le fichier sur le serveur NetWitness.
  4. Connectez-vous en tant que root.
  5. Modifiez les autorisations dans le fichier à exécuter.
  6. Exécutez le fichier suivant :

    ./BIOS_V7P04_LN_2.2.3.BIN

  7. Redémarrez le système lorsque l’exécution est terminée et qu’un redémarrage est demandé.

Remarque : la procédure d’installation du BIOS dure environ 10 minutes.

Localiser les packages 10G Decoder

Les packages requis pour configurer le 10G Decoder doivent déjà être présents sur l’image d’installation du Decoder. Vous ne devriez pas avoir besoin d’installer des packages supplémentaires.

Vérifier l’installation des packages 10G Decoder

L’installation des packages 10G Decoder est gérée automatiquement. Par conséquent, aucune action n’est nécessaire pour activer la fonctionnalité 10G.

  • Si vous avez mis à niveau les packages de noyau dans le cadre d’une mise à niveau, un redémarrage est nécessaire. Le système d’exploitation recompile et installe les pilotes pour le noyau mis à niveau.
  • Vous pouvez vérifier que l’installation a réussi si vous voyez des interfaces PFRINGZC supplémentaires lorsque vous sélectionnez l’adaptateur de port de capture décrit ci-dessous.

Configurer le 10G Decoder

Procédez comme suit pour configurer le 10G Decoder :

  1. Dans la vue Explorateur de Decoder, cliquez avec le bouton droit de la souris sur Decoder et sélectionnez Propriétés.
  2. Dans le menu déroulant des propriétés, sélectionnez reconfig et saisissez les paramètres suivants :
    update=1 op=10g
    Ces paramètres ajustent le pipeline de traitement du paquet Decoder pour permettre une vitesse de transfert de données brutes supérieure, mais une capacité d’analyse moindre.
  3. Dans la vue Explorateur de Decoder, cliquez avec le bouton droit de la souris sur base de données et sélectionnez Propriétés.
  4. Dans le menu déroulant Propriétés, sélectionnez reconfig et saisissez les paramètres suivants :
    update=1 op=10g
    Ces paramètres ajustent la base de données de paquets pour utiliser les tailles des fichiers très volumineux et les E/S directes.
  5. Sélectionnez l’adaptateur de port de capture. Les options sont les suivantes (dans les exemples suivants, « p1p1 » et « p1p2 » sont des espaces réservés et doivent être remplacés par vos propres noms d'interface) :
    • Port de capture unique - PFRINGZC,p1p1 ou PFRINGZC,p1p2
    • Capture des deux ports - Sélectionnez PFRINGZC,P1P1 et dans la vue Explorateur, définissez capture.device.params = device=zc:p1p2,zc:p1p1
  6. Si le thread d'écriture rencontre des difficultés à maintenir la vitesse de capture, vous pouvez procéder comme suit :

    Remplacez /datebase/config/packet.integrity.flush par normal.

    Remarque : vous pouvez ajuster packet.file.size en lui attribuant une valeur plus élevée, mais inférieure à 10 Go, car le fichier entier est mis en mémoire tampon.

  7. (Facultatif) L’analyse d’application sollicite de manière très intensive le CPU et peut entraîner le Decoder à supprimer des paquets. Pour limiter les suppressions causées par l’analyse d’application, définissez /decoder/config/assembler.parse.valve sur true. Cela génère les résultats ci-dessous :

    • Lorsque l’analyse de sessions provoque un goulot d’étranglement, les analyseurs d’applications (HTTP, SMTP, FTP, etc.) sont temporairement désactivés.
    • Les sessions ne sont pas supprimées lorsque les analyseurs d’applications sont désactivés ; mais la fidélité de l’analyse réalisée sur ces sessions peut être remise en cause.
    • Les sessions analysées lorsque les analyseurs d’application sont désactivés ont toujours un méta-réseau associé (depuis l’analyseur de réseau).
    • La statistique /decoder/parsers/stats/blowoff.count affiche le nombre total de sessions ayant contourné les analyseurs d’applications (l’analyse de réseau est toujours effectuée).
    • Lorsque l’analyse des sessions n’est plus à l’état de goulot d’étranglement, les analyseurs d’applications sont automatiquement réactivés.
    • Le pool de sessions de l’assembleur doit être suffisamment large pour ne pas contraindre les sessions.
    • Vous pouvez déterminer si des sessions sont forcées par la statistique /decoder/stats/assembler.sessions.forced (elle augmentera). En outre, /decoder/stats/assembler.sessions se trouvera parmi plusieurs centaines de /decoder/config/assembler.session.pool.
  8. (Facultatif) Si vous avez besoin d’ajuster la taille de MTU pour la capture, ajoutez le paramètre snaplen à capture.device.params. Contrairement aux versions précédentes, snaplen ne doit pas être arrondi à une limite spécifique. Le Decoder ajuste automatiquement l’ensemble MTU sur les interfaces de capture.

  9. Les paramètres de configuration suivants sont obsolètes et ne sont plus nécessaires :

    • core= parameter dans capture.device.params
    • Tous les fichiers de configuration sous le répertoire /etc/pf_ring

    Remarque : un périphérique Ethernet installé après la création d’images ne nécessite pas de configuration pour une utilisation en tant que périphérique de capture. Il ne requiert pas de configuration s’il est utilisé comme interface réseau ou pour que les outils système y accèdent sans configuration manuelle.

Paramètres de configuration par défaut

Les paramètres de configuration par défaut sont répertoriés ci-dessous. Les paramètres réels peuvent varier selon la quantité de mémoire et les ressources de CPU disponibles.

  1. Paramètres de pool des paquets et sessions (sous /decoder/config) :
    • pool.packet.pages = 1000000
    • pool.session.pages = 300000
  2. Taille de blocs d’écriture des paquets sous (/database/config/packet.write.block taille) définie sur filesize.

    Remarque : cela permet de configurer le Decoder pour mettre en mémoire tampon les fichiers volumineux et y accéder en écriture à l’aide des E/S directes pour des performances maximales.

  3. Nombre de threads de l’analyse (sous /decoder/config).

    parse.threads =12

Considérations relatives au stockage

Lors d’opérations de capture à un débit de 10G, le système de stockage qui héberge les bases de données de paquets et de méta doit être en mesure de supporter un débit d’écriture de 1 400 Mo/s.

Utilisation du matériel de la gamme 4S (avec deux ou plusieurs unités DAC)

Le matériel de la série 4S est équipé d’un contrôleur SAS RAID autorisant un débit d’E/S agrégé de 48 Gbits/s. Il est doté de 8 ports externes de 6 Gbits, organisés en 2 câbles SAS à 4 voies. La configuration recommandée pour 10G consiste à répartir au moins deux unités DAC sur ces deux connecteurs externes. Par exemple, connectez un DAC à un port de la carte SAS, puis un autre DAC à l’autre port de la carte SAS.

Pour les environnements comportant plus de deux DAC, ne les reliez pas à chaque port de manière équilibrée. Un recâblage des DAC dans un déploiement existant peut être nécessaire, mais sans avoir d’incidence sur les données qui ont déjà été capturées sur le Decoder.

Si vous souhaitez renforcer la capacité de stockage, utilisez le script actuellement disponible NwMakeArray pour provisionner les unités DAC. Le script ajoute automatiquement un DAC par exécution (c’est-à-dire que si vous ajoutez trois DAC, le script doit être exécuté trois fois), en ajoutant les DAC à la configuration de NwDecoder10G comme points de montage distincts. Les points de montage indépendants sont importants, car ils permettent à NwDecoder10G de distinguer les E/S en écriture de la capture des E/S en lecture requises pour répondre aux demandes de contenu de paquet.

Utilisation de SAN et d’autres configurations de stockage

Le Decoder accepte toutes les configurations de stockage pouvant satisfaire les besoins en débit soutenu. La liaison FC de 8 Gbits standard vers un réseau SAN ne suffit pas pour stocker des données de paquets à 10G. Pour utiliser un réseau SAN, il faut parfois réaliser une agrégation sur plusieurs cibles à l’aide d’un schéma RAID logiciel. Par conséquent, les environnements utilisant un SAN doivent configurer la connectivité vers le SAN à l’aide de plusieurs FC.

Considérations relatives à l’analyse et au contenu

L’analyse de paquets bruts à vitesses élevées présente des défis spécifiques. Étant donné les débits élevés de sessions et de paquets, l’efficacité de l’analyse est fondamentale. Si la productivité d’un seul analyseur n’est pas satisfaisante (examen trop long des paquets), le système entier peut être ralenti au point que des paquets soient supprimés au niveau de la carte.

Pour réaliser un test initial à 10G, lancez uniquement les analyseurs natifs (excepté SMB/WebMail). Utilisez les analyseurs natifs pour établir les performances de base, avec un nombre limité ou nul de paquets supprimés. Ne téléchargez pas de contenu Live avant cette opération. Il convient de vérifier que le système ne rencontre pas de problèmes au cours de la capture à vitesses élevées.

Dès que le système est opérationnel et fonctionne parfaitement, vous pouvez ajouter peu à peu du contenu Live, notamment des analyseurs. 

Bonnes pratiques

Si vous mettez à jour un système actuellement déployé ou déployez un nouveau système, il est recommandé d’utiliser les bonnes pratiques suivantes afin de minimiser les risques de perte de paquets. Une réserve est émise dans le cas de la mise à jour d’un déploiement 10G sans ajouter de trafic supplémentaire. Par exemple, un Decoder actuel capturant une carte 10G avec un débit soutenu de 2G ne doit voir aucune différence de performances, excepté si la mise à jour comprend l’ajout d’un trafic supplémentaire pour la capture.

  • Intégrer les analyseurs de base (excepté SMB/Webmail, qui ont généralement une utilisation CPU élevée) et surveiller les pertes de paquets potentielles.
  • Si vous ajoutez d’autres analyseurs, ajoutez-en un ou deux à la fois.
  • Mesurer l’impact sur les performances du contenu nouvellement ajouté, particulièrement durant les pics de trafic.
  • Si des suppressions surviennent alors qu’il n’y en avait pas auparavant, désactivez tous les analyseurs nouvellement ajoutés et activez un seul analyseur à la fois pour mesurer son impact. Cela permet d’identifier individuellement les analyseurs à l’origine des effets préjudiciables sur les performances. Pour obtenir des performances optimales, remaniez ou réduisez les fonctionnalités de chaque analyseur en fonction des besoins du client.
  • Bien que leur impact sur les performances soient minimes, les flux doivent également être réexaminés et ajoutés à une approche progressive afin de mesurer l’impact sur les performances.
  • Les règles d’application ont également tendance à impacter les performances dans une faible mesure ; il est donc une fois encore conseillé de ne pas ajouter un grand nombre de règles en une seule fois, sans mesurer au préalable leur impact.

Enfin, les modifications de configuration recommandées décrites dans la section Configuration permettent de réduire les problèmes potentiels.

Contenu Live testé

Les analyseurs suivants peuvent tous (mais pas individuellement) être exécutés à 10G sur le jeu de données de test :

  • Contenu MA (7 analyseurs Lua, 1 flux, 1 règle d’application)
  • 4 flux (alert ids info, nwmalwaredomains, warning et suspicious)
  • 41 règles d’application
  • DNS_verbose_lua (disable DNS)
  • fingerprint_javascript_lua
  • fingerprint_pdf_lua
  • fingerprint_rar_lua
  • fingerprint_rtf_lua
  • MAIL_lua (disable MAIL)
  • SNMP_lua (disable SNMP)
  • spectrum_lua
  • SSH_lua (disable SSH)
  • TLS_lua
  • windows_command_shell
  • windows_executable

NON TESTÉ :

  • SMB_lua, SMB natif désactivé par défaut
  • html_threat

AUTRE :

  • HTTP_lua réduit le taux de capture de > 9G à < 7G. À un débit tout juste inférieur à 5G, cet analyseur peut remplacer le natif sans dégrader les performances (en plus des éléments répertoriés dans la liste ci-dessus). 
  • Avec xor_executable, les ressources de CPU seront utilisées à 100 % lors de l’analyse, et les performances du système peuvent considérablement chuter au moment de la sauvegarde.

Ajustements de l’agrégation sur la base du contenu Live testé

Un Decoder 10G peut assurer l’agrégation sur un seul Concentrator tout en fonctionnant à des vitesses de 10G. Les déploiements utilisant Malware Analysis, Event Stream Analysis, Warehouse Connector et Reporting Engine sont susceptibles d’avoir un impact sur les performances et peuvent entraîner une perte de paquets.

Pour le scénario testé, le Concentrator agrège les données à un débit de 45 à 70 000 sessions/s. Le 10G Decoder capture des données à un débit de 40 à 50 000 sessions/s. Avec le contenu défini ci-dessus, cela représente environ 1,5 à 2 millions de métas/s. En raison du volume élevé des taux de sessions, les modifications de configuration suivantes sont recommandées :

  • L’agrégation nice sur le Concentrator limite l’impact des performances sur le 10G Decoder. La commande suivante active l’agrégation nice.
    /concentrator/config/aggregate.nice = true
  • En raison du volume élevé de sessions sur le Concentrator, vous pouvez envisager d'activer le mode Valeurs parallèles sur le Concentrator en définissant /sdk/config/parallel.values sur 16. Cela améliore les performances d'Investigation lorsque le nombre de sessions par seconde dépasse 30 000.
  • Si des flux d’agrégation multiples sont nécessaires, l’impact sur le Decoder est moindre lorsque l’agrégation est réalisée à partir du Concentrator.
  • Une révision ultérieure du contenu et de l'analyse est requise pour les déploiements où vous souhaitez utiliser d'autres composants NetWitness Platform (par exemple, Warehouse Connector, Malware Analysis, ESA et Reporting Engine).

Optimiser les opérations de lecture/écriture lors de l'ajout d'un nouveau stockage

Un décodeur 10G est optimisé pour décaler les opérations de lecture et d'écriture sur plusieurs volumes afin que le fichier en cours de rédaction soit sur un volume différent du fichier suivant qui sera écrit. Cela permet d’obtenir un débit maximal sur le volume RAID lors de la lecture des données du dernier fichier écrit lors de l'écriture du fichier actuel sur un volume différent. Toutefois, si les volumes sont ajoutés après qu'un Decoder a été utilisé, la capacité de décaler est limitée parce qu'un ou plusieurs volumes sont déjà pleins, de sorte que le nouveau volume est le seul endroit où de nouveaux fichiers peuvent être écrits.

Pour remédier à cette situation, un administrateur peut exécuter une commande stagger sur une base de données NetWitness Platform existante (paquet, log, métadonnées ou session), qui possède au moins deux volumes, pour décaler les fichiers sur tous les volumes dans le modèle de lecture/écriture le plus optimal. Le principal cas d'utilisation est lorsque le nouveau stockage est ajouté à un Decoder existant et que vous souhaitez décaler les volumes AVANT de redémarrer la capture.

Les nœuds de configuration de cette commande sont les bases de données de sessions, métadonnées et paquets. Chacune d’elles se trouve sous /database/config, qui est généralement un nœud racine. Les nœuds de configuration d'un Decoder sont :

  • /database/config/packet.dir
  • /database/config/meta.dir
  • /database/config/session.dir

Le Guide d'optimisation de la base de données principale de NetWitness Platform contient des informations sur la mise en forme de ces configurations.

La commande stagger n'est généralement utile que pour un Decoder 10G et généralement uniquement pour la base de données de paquets. Des performances maximales sont obtenues pour stocker et récupérer des paquets lorsque plusieurs volumes sont présents. Dans ce scénario, le Decoder remplit toujours le volume en conservant le plus d’espace disponible possible. Lorsque les volumes sont à peu près de la même taille, il en résulte un motif d'écriture échelonnée, qui permet un débit maximal pour la lecture et l'écriture sur tous les volumes. Toutefois, cela se produit naturellement lorsque plusieurs volumes de stockage de paquets sont présents au moment où le Decoder est déployé pour la première fois.

Un exemple d'utilisation typique consiste à ajouter plus de stockage à un Decoder existant pour augmenter la rétention. Toutefois, lors de l'ajout de stockage à un déploiement qui a déjà rempli les volumes existants avec des paquets stockés, le Decoder occupera naturellement le nouveau stockage avec des paquets avant de déployer tous les paquets sur le stockage existant. Il en résulte un modèle de lecture/écriture sous-optimal, car la plupart des lectures se produiront sur le même volume que celui en cours de rédaction. Lors d’un déploiement 10G, les lectures sont bloquées à partir du volume lorsque les écritures se produisent. Cela n'arrête pas TOUTES les lectures sur ce volume, car le fichier est mis en mémoire tampon avant d'être écrit, mais il entraîne des performances de lecture non optimales.

Avec la commande stagger, vous pouvez ajouter plus de stockage et obtenir ensuite du service qu’il répartisse naturellement les fichiers sur TOUS les volumes (existants et nouveaux) afin que les performances de lecture soient optimisées.

Attention : Cette commande ne doit être exécutée qu'APRÈS le montage du stockage et la configuration du Decoder effectués pour l'utiliser (par exemple, après avoir ajouté le ou les points de montage à packet.dir).

L'inconvénient de cette commande est qu'elle peut prendre un certain temps à répartir les données et le Decoder ne doit pas effectuer de captures pendant l'opération de répartition.

Flux de travail recommandé :

  1. Ajoutez tout le stockage et configurez les points de montage.
  2. Ajoutez de nouveaux points de montage du stockage à packet.dir (ou session.dir/meta.dir) et redémarrez le service (très important !).
  3. Assurez-vous que la capture est arrêtée.
  4. Exécutez l’opération de répartition, mais assurez-vous que la connexion qui a initié l'opération ne s’interrompe pas avant la fin de l'opération. Si la connexion est terminée, l'opération de répartition sera annulée. Si l'opération est annulée, les fichiers déjà répartis resteront en place. L'opération peut être reprise en exécutant de nouveau la même commande (le travail déjà fait n'aura pas besoin d'être refait). Si vous exécutez stagger à partir de nwconsole, exécutez la commande timeout 0 avant d'envoyer la commande stagger. Cela empêchera que le délai de temporisation normal de 30 secondes ne s’exécute.
  5. Démarrez la capture après la fin de la commande stagger.

Voici les paramètres de la commande :

  • type : la base de données qui sera répartie (session, métadonnée ou paquet). En général, seule la base de données de paquets est utile pour la répartition, mais il est possible d’exécuter la session ou la base de données de métadonnées lorsque plusieurs volumes sont présents pour ces bases de données. Étant donné que la session et les bases de données de métadonnées écrivent beaucoup moins de données que la base de données de paquets, en général la répartition de ces bases de données se traduit par des gains de performances beaucoup moins perceptibles.
  • dryRun - Si true (la valeur par défaut), seule une description des opérations en passe d’être exécutées sera renvoyée. Si false, alors les fichiers seront effectivement déplacés vers un modèle de lecture/écriture optimal. Vous DEVEZ transmettre false pour répartir réellement les fichiers.

Exemple d'utilisation de NwConsole :

login <decoder>:50004 <username> <password>

timeout 0

send /database stagger type=packet dryRun=false

Si vous exécutez cette commande via l'API RESTful, veuillez passer le paramètre expiry=0 supplémentaire pour empêcher un délai d'attente du service. Vous devez également vous assurer que le client HTTP ne se déconnecte pas avant la fin de l'opération.

 

You are here
Table of Contents > Procédures supplémentaires de Decoder et Log Decoder > Configurer la fonction 10G

Attachments

    Outcomes