Introduction à PF_RING

mai 29, 2013  |   Blog   |     |   Commentaires fermés sur Introduction à PF_RING

Introduction à PF_RING

PF_RING est une bibliothèque réseau Opensource permettant de capturer un flux réseau sur un lien à haut débit (>1Gbps). Une fois ce trafic capturé, il est possible de l’analyser et/ou le manipuler.

Par exemple, il est envisageable d’utiliser PF_RING afin de mettre en place un repartiteur de charge ou un pare-feu.

PF_RING au niveau du système

Commençons par étudier comment se place PF_RING sur votre système (Linux exclusivement).

PF_RING est intégré au noyau et est segmenté en deux parties.

Le premier est situé au niveau du noyau linux. Il permet la copie bas niveau des paquets au sein de PF_RING.

La seconde permet de fournir une interface avec l’espace utilisateur. Pour ce faire, l’utilisateur dispose d’un nouveau socket “PF_RING”.

Ce socket est alors disponible sur :

  • Toute interface physique

  • Une file d’attente (pour les cartes réseau à plusieurs files)

  • Toute interface virtuelle du système.

Le fonctionnement de PF_RING

L’idée principale de PF_RING est de traiter la capture des paquets directement au niveau du noyau (au lieu du niveau applicatif) et permet d’envoyer aux applications uniquement les paquets qui lui sont pertinents. De ce fait, l’application n’a plus besoin de consommer des ressources à trier les paquets.

Il est alors possible de définir des filtres du type [vlan, protocol, ip source, ip destination, port source, port destination], mais PF_RING reste compatible avec les filtres de type BPF (Berkeley Packet Filter) afin de selectionner les paquets à relever. De la sorte, l’application n’a plus à trier les paquets qu’elle reçoit, ce qui permet donc :

  • d’économiser une quantitée importante de temps CPU.

    • Permet de traiter plus de paquets

  • de recevoir que les paquets pertinants.

    • Reduit drastiquement le nombre de paquets perdus

Il est à noter que PF_RING est compatible avec toutes les cartes réseau. Cependant, il y a des fonctionnalités avancées pour certains modèles de cartes (Intel 82599 ou Silicom Redirector par exemple). Ces fonctionnalités comme le DNA (Direct NIC Access) consistent à permettre aux application de mapper directement les registres et la mémoire de la carte réseau. Cette approche permet de déléguer la copie des données de la carte vers PF_RING au NPU (Networking Processing Unit) et permet d’aléger encore les taches du CPU. Cette fonctionnalité permet d’accroitre encore les performances de captures puisque dans ce cas, on evite complétement la copie des paquets entre la carte et les structures reseau du noyau. Cependant, l’utilisation de cette technologie ne permet pas l’utilisation de certaines autres fonctionnalités telles que le “packet reflection” et le “packet filtering”. (fonctionnalités décrites dans la partie suivante de cet article).

Une autre fonctionnalité est aussi disponible afin de gagner encore en performance de capture, le “packet clustering” qui, quant à lui, permet de distribuer les paquets relevés sur un socket PF_RING. De cette facon, pour des applications pouvant se répartir le traitement des paquets, il est possible de connecter plusieurs instances de ces applications sur le même socket afin d’augmenter encore une fois les performance de traitement lors d’une forte charge.

Il existe aussi plusieurs mode transparent de PF_RING qui permettent alors de fonctionner soit en parralèlle de la pile réseau standard et garantir la préservation du service hébergé (transparent_mode=0 et transparent_mode=1), soit en dédiant l’interface à la capture afin de garantir une capture plus efficace ( transparent_mode=2).

Enfin, il faut noté que PF_RING dispose d’une interface avec libpcap. Pour ces applications, il existe deux cas :

  • L’application a été compilée avec une version ancienne de libpcap : Dans ce cas, l’application ne benéficiera pas des avantages de PF_RING

  • L’application a été compilée avec une version à jour de libpcap : Dans ce cas, l’application pourra bénéficier des avantages de PF_RING.

Autres applications de PF_RING

Packet reflection

Le packet reflection de PF_RING permet de créer un filtre afin de rediriger au niveau du noyau et sans remonter les couches réseau les paquets arrivants sur une interface vers une autre. Cette fonctionnalité peut-être assimiler à du port mirroring amélioré grâce à la selection des paquets à retransmettre.

Grâce à cette fonctionnalité, vous serez alors, par exemple, capable de rediriger uniquement le trafic issu du réseau 11.22.33.0/24 et a destination du port 80 arrivant vers eth0 vers eth1 qui pourrait être connectée à une sonde pour analyser le flux (Lors d’une attaque par exemple).

Packet filtering

Comme son nom le laisse penser, le packet filtering permet de filtrer les paquets arrivants sur une interface. La structure et le fonctionnement de PF_RING étant plus rapide que la structure réseau standard du noyau, il est alors possible de ne pas relever les paquets qui correspondent a un filtre à un niveau plus bas, plus proche du matériel, et donc, en consommant moins de CPU.

De plus, certaines cartes réseau intègrent parfois la possibilité de filtrer les paquets au niveau matériel mais ces listes de filtrages sont généralement complexes à manipuler. En revanche, PF_RING est en mesure de detecter si la carte réseau en place dans le serveur est compatible avec le filtrage matériel et, si tel est le cas, placer les filtres définis par l’application (telle que ntop, snort ou tout autre application compilée pour PF_RING), directement au niveau de la carte.

Quelques chiffres

Ci-dessous, quelques chiffres comparatifs (fournis par ntop.org) entre une capture avec libpcap (grâce au binaire pcount) et pf_ring (grâce au binaire pfcount).

Ces deux applications permettent de compter les paquets injectés dans le réseau et permettent d’estimer les performances des différents modes tant en bande passante qu’en perte de paquet.

L’option -a de ce dernier permet d’activer l’inspection des paquets capturés.

Quand l’environnement le permet (c-a-d quand le noyau gère la relève des paquets), les tests ont été effectués avec les trois modes de transparence de PF_RING :

  • Transparent=0 : Les paquets sont relevé par le mechanisme standard du noyau et sont envoyés à la fois vers PF_RING et vers les autres mécanismes du noyau. Supporté par toutes les cartes réseau.

  • Transparent=1 : Les paquets sont envoyés par le pilotes de la carte réseau dans PF_RING. Cependant les paquets sont toujours distribués aux autres composants réseaux du noyau.

  • Transparent=2 : Les paquets sont envoyés par le pilotes de la carte réseau dans PF_RING. Les paquets ne sont plus envoyés aux autres composants réseau. Ce mode implique que l’interface réseau ne possède plus de connectivité avec le réseau mais permet d’effectuer une capture plus efficace.

e1000e
Application transparent_mode=0 transparent_mode=1 transparent_mode=2
pfcount (with -a flag) 757 Kpps 795 Kpps 843 Kpps
pfcount (without -a flag) 661 Kpps 700 Kpps 762 Kpps
pcount (with PF_RING-aware libpcap) 730 Kpps 763 Kpps 830 Kpps
pcount (with vanilla libpcap) 544 Kpps
pfcount (with PF_RING DNA) 1’170 Kpps

 

igb
Application transparent_mode=0 transparent_mode=1 transparent_mode=2
pfcount (with -a flag) 650 Kpps 686 Kpps 761 Kpps
pfcount (without -a flag) 586 Kpps 613 Kpps 672 Kpps
pcount (with PF_RING-aware libpcap) 613 Kpps 644 Kpps 711 Kpps
pcount (with vanilla libpcap) 544 Kpps
pfcount (with PF_RING DNA) 1’488 Kpps

Bibliographie

http://www.ntop.org/products/pf_ring/

http://www.ntop.org/products/pf_ring/dna/

http://www.ntop.org/pf_ring/exploiting-hardware-filtering-in-pf_ring-aware-apps-snort/

http://www.ntop.org/solutions/softwarehardware-packet-filtering/

http://www.ntop.org/support/documentation/

http://www.ntop.org/pf_ring/introducing-pf_ring-dna-direct-nic-access/

Les commentaires sont fermés.