Exploiting Hardware Filtering in PF_RING-aware apps, Snort…

Posted · Add Comment

Introduction

PF_RING filters have been designed to be efficient and versatile. PF_RING-based applications can use them for both reducing the amount of packets they need to process, and passing incoming packets to kernel plugins for further processing.

Years ago, hardware packet filtering was limited to costly FPGA-based NICs, whereas today it is available also on commodity adapters such as Silicom 1/10 Gbit Director card, and Intel 82599-based 10 Gbit network adapters.

 

Filtering in PF_RING 5.2

Although past PF_RING versions supported limited hardware filtering, in PF_RING 5.2 we have completely redesigned packet filtering so that applications can use a single and consistent packet filtering API, letting PF_RING do the magic based on the hardware NIC being used. This means that you need to code the application once, regardless of the type of NIC being used, and let PF_RING set the native filter type. As you can see from the figure below there are many combinations we support in PF_RING, and using a single API is pre-requisite for avoid wasting time supporting all of them.

When you set a filter, you can either specify it as NIC native filter (e.g. silicom_redirector_hw_rule) or as PF_RING generic filter (e.g. filtering_rule/hash_filtering_rule). In the former case you have full control over the filter at the cost of being unable to seamlessly run the code over various adapter types. In the latter case, you code once and let PF_RING convert the filter format into native, hardware filter, based on the NIC type you use.

Although all hardware filter types are very efficient being them executed in hardware, they are not all alike. As of today we support:

  • 82599-based NICs (see the Intel 82599 datasheet for more details)
    • Up to 32k FlowDirector filters (IPv4/v6 hash_filtering_rule in PF_RING parlance)
    • Up to 128 5-tuple filters (IPv4/v6 filtering_rule in PF_RING parlance)
  • Silicom Director
    • Up to 1’000 filters per port (IPv4-only flexible filters)

In the case of Silicom Director, it is also possible to execute in hardware actions across ports (e.g. mirror packets matching a given filters across ports); on non-Director NICs you can do that  too at the cost of doing it in the CPU.

 

Using Hardware Filters

In order to demonstrate the power and usefulness of PF_RING filters, we have enhanced the pfcount demo application so that it adds a filter (-u command line option) for dropping incoming packets. The pfcount_82599 demo application shows how to set native filters.

 

Hardware Filtering in Snort

For all snort users, we have enhanced our PF_RING DAQ module, so that snort can transparently set “drop filters” whenever bad packets are detected. This is a fantastic way to address DDoS attacks and drop in hardware nasty packets that would waste too many CPU cycles.As snort PF_RING DAQ can work in both IDS (Intrusion Detection System) and IPS (Intrusion Prevention System) mode, so hardware filtering in IPS mode is a very nice thing to have.

 

If You Don’t Own a Hardware-Filtering NIC…

Software PF_RING filters are still enabled when hardware filtering is used. This because it is not always possible to filter all the traffic you would like in hardware. So you can use PF_RING filtering as you have done so far, although you have to be aware that switching to a hardware filtering NIC allows your CPU to offload filters to the NIC and thus preserve precious CPU cycles for packet processing.

 

Notes on 82599 filters

  • In order to enable hardware filters you need to load the ixgbe module with specific parameters. Example: insmod ixgbe.ko  RSS=0,0,0,0 FdirMode=2,2,2,2 FdirPballoc=3,3,3,3
  • Filters are not used just for pass/drop actions, but also for steering packets to specific cores/RX queues. For instance you can say: all incoming TCP packets on port 80 must be diverted to RX queue 3. So you can bind you HTTP analysis application to queue ethX@3 and forget all other queues.
  • You can simultaneously set both 5-tuple and FlowDirector filters. However there are some limitations in the silicon, so please refer to the 82599 datasheet for more information about this subject.