Deep Packet Inspection: compare the performance between libnetfilterqueue, NFHOOK and eBPF XDP

Project Description

The objective is to benchmark 3 different methods to perform deep packet inspection (layer 4 payload string search):

  • Use the userland libnetfilter_queue facility (along with the netfilter NFQUEUE target)
  • Use an in-kernel custom hook (via NF_HOOK)
  • Use an eBPF XDP filter

Performance will be measured with two metrics: - response time - throughput

Goal for this Hackweek

  • Develop the 3 use cases (simple programs)
  • Create a simple benchmark to compare the 3 use cases
  • Obtain metrics for response times and throughput for the 3 use cases.

Resources

  • https://netfilter.org/projects/libnetfilter_queue/index.html
  • https://linux-kernel-labs.github.io/refs/heads/master/labs/networking.html#netfilter-1
  • https://en.wikipedia.org/wiki/ExpressDataPath

Code Repository

  • https://github.com/susenguyen/Hackweek_23

Looking for hackers with the skills:

c ebpf netfilter

This project is part of:

Hack Week 23

Activity

  • about 1 year ago: tracy.walker liked this project.
  • about 1 year ago: feih liked this project.
  • about 1 year ago: nguyens started this project.
  • over 1 year ago: nguyens removed keyword kerneldevelopment from this project.
  • over 1 year ago: nguyens added keyword "c" to this project.
  • over 1 year ago: nguyens added keyword "kerneldevelopment" to this project.
  • over 1 year ago: nguyens added keyword "ebpf" to this project.
  • over 1 year ago: nguyens added keyword "netfilter" to this project.
  • over 1 year ago: nguyens originated this project.

  • Comments

    • feih
      about 1 year ago by feih | Reply

      This could be interesting for NeuVector engineering team, I could connect you to the network filter engineers if it makes sense.

    • nguyens
      about 1 year ago by nguyens | Reply

      Thanks sure. Let me know if you'd like me to report my results to anyone

    Similar Projects

    FastFileCheck work by pstivanin

    Description

    FastFileCheck is a high-performance, multithreaded file integrity checker for Linux. Designed for speed and efficiency, it utilizes parallel processing and a lightweight database to quickly hash and verify large volumes of files, ensuring their integrity over time.

    https://github.com/paolostivanin/FastFileCheck

    Goals

    • Release v1.0.0

    Design overwiew:

    • Main thread (producer): traverses directories and feeds the queue (one thread is more than enough for most use cases)
    • Dedicated consumer thread: manages queue and distributes work to threadpool
    • Worker threads: compute hashes in parallel

    This separation of concerns is efficient because:

    • Directory traversal is I/O bound and works well in a single thread
    • Queue management is centralized, preventing race conditions
    • Hash computation is CPU-intensive and properly parallelized


    ESETv2 Emulator / interpreter by m.crivellari

    Description

    ESETv2 is an intriguing challenge developed by ESET, available on their website under the "Challenge" menu. The challenge involves an "assembly-like" language and a Python compiler that generates .evm binary files.

    This is an example using one of their samples (it prints N Fibonacci numbers):

    .dataSize 0
    .code
    
    loadConst 0, r1 # first
    loadConst 1, r2 # second
    
    loadConst 1, r14 # loop helper
    
    consoleRead r3
    
    loop:
        jumpEqual end, r3, r15
    
        add r1, r2, r4
        mov r2, r1
        mov r4, r2
    
        consoleWrite r1
    
        sub r3, r14, r3
        jump loop
    end:
    hlt
    

    This language also supports multi-threading. It includes instructions such as createThread to start a new thread, joinThread to wait until a thread completes, and lock/unlock to facilitate synchronization between threads.

    Goals

    • create a full interpreter able to run all the available samples provided by ESET.
    • improve / optimize memory (eg. using bitfields where needed as well as avoid unnecessary memory allocations)

    Resources

    Achivements

    Project still not complete. Added lock / unlock instruction implementation but further debug is needed; there is a bug somewhere. Actually the code it works for almost all the examples in the samples folder. 1 of them is not yet runnable (due to a missing "write" opcode implementation), another will cause the bug to show up; still not investigated, anyhow.


    FizzBuzz OS by mssola

    Project Description

    FizzBuzz OS (or just fbos) is an idea I've had in order to better grasp the fundamentals of the low level of a RISC-V machine. In practice, I'd like to build a small Operating System kernel that is able to launch three processes: one that simply prints "Fizz", another that prints "Buzz", and the third which prints "FizzBuzz". These processes are unaware of each other and it's up to the kernel to schedule them by using the timer interrupts as given on openSBI (fizz on % 3 seconds, buzz on % 5 seconds, and fizzbuzz on % 15 seconds).

    This kernel provides just one system call, write, which allows any program to pass the string to be written into stdout.

    This project is free software and you can find it here.

    Goal for this Hackweek

    • Better understand the RISC-V SBI interface.
    • Better understand RISC-V in privileged mode.
    • Have fun.

    Resources

    Results

    The project was a resounding success add-emoji Lots of learning, and the initial target was met.


    Add a machine-readable output to dmidecode by jdelvare

    Description

    There have been repeated requests for a machine-friendly dmidecode output over the last decade. During Hack Week 19, 5 years ago, I prepared the code to support alternative output formats, but didn't have the time to go further. Last year, Jiri Hnidek from Red Hat Linux posted a proof-of-concept implementation to add JSON output support. This is a fairly large pull request which needs to be carefully reviewed and tested.

    Goals

    Review Jiri's work and provide constructive feedback. Merge the code if acceptable. Evaluate the costs and benefits of using a library such as json-c.


    Model checking the BPF verifier by shunghsiyu

    Project Description

    BPF verifier plays a crucial role in securing the system (though less so now that unprivileged BPF is disabled by default in both upstream and SLES), and bugs in the verifier has lead to privilege escalation vulnerabilities in the past (e.g. CVE-2021-3490).

    One way to check whether the verifer has bugs to use model checking (a formal verification technique), in other words, build a abstract model of how the verifier operates, and then see if certain condition can occur (e.g. incorrect calculation during value tracking of registers) by giving both the model and condition to a solver.

    For the solver I will be using the Z3 SMT solver to do the checking since it provide a Python binding that's relatively easy to use.

    Goal for this Hackweek

    Learn how to use the Z3 Python binding (i.e. Z3Py) to build a model of (part of) the BPF verifier, probably the part that's related to value tracking using tristate numbers (aka tnum), and then check that the algorithm work as intended.

    Resources


    Tracing system calls with eBPF by doreilly

    Description

    Many security tools need to record system calls like execve. Using the Linux audit system for this can have a detrimental performance impact in some cases.

    Goals

    The goal is to investigate eBPF as an alternative and do some benchmarking to see the impact and how it compares to using the audit subsystem.

    Progress

    BPF done - traceexec

    Benchmark report

    Resources

    eBPF doc

    libbpf

    libMicro benchmark tool