BPF Guide

API Documentation

Overview

Programs are loaded into MITIGATOR as ELF object files. They can use the API functions from mitigator_bpf.h (download).

The compatibility policy applies to BPF.

A minimal program must place metadata and code into the correct sections of the object file using macros:

#include "mitigator_bpf.h"

ENTRYPOINT enum Result
program(Context ctx) {
    return RESULT_PASS;
}

PROGRAM_DISPLAY_ID("Example v0.1")

Typically, programs are written in C and compiled with clang (EBPF support added in GCC 10). Example:

clang -c -emit-llvm -fno-stack-protector -O2 program.c -o - | \
    llc -march=bpf -filetype=obj -o=program.o

What Not To Do

Do Not Harm The Attack Source

Do not send response traffic with the intent to harm the attack source. The source might not be an attacker but a vulnerable server (reflection attack participant), which would harm innocent parties. Writing malicious programs is a crime in most countries.

Do Not Try To Overcome API Restrictions

Programmable filter is a powerful countermeasure. Some capabilities are intentionally left off to prevent network damage. Others may be temporarily unsupported. Share your ideas with the developers.

EBPF Restrictions in MITIGATOR

Headers Below Network-Layer Are Unavailable

This restriction exists because programs operate within protection policies where Ethernet and VLAN headers do not need to be analyzed (MITIGATOR handles this). On the other hand, modifying such headers would be dangerous for the network where MITIGATOR is deployed.

BPF_ABS And BPF_IND Arguments Are Not Supported

These arguments are supported by the Linux kernel for packet data access. This is relevant only when rewriting cBPF to EBPF in assembler.

Functions you can use instead:

• packet_network_header() — pointer to data starting from the L3 header;
• packet_transport_payload() — pointer to TCP/UDP payload.