Справочник

Документация API

Обзор

Программы загружаются в MITIGATOR в виде объектных файлов ELF. Они могут пользоваться функциями API из mitigator_bpf.h (скачать).

Политика совместимости распространяется на BPF.

Минимальная программа должна помещать метаданные и код в правильные секции объектного файла с помощью макросов:

#include "mitigator_bpf.h"

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

PROGRAM_DISPLAY_ID("Example v0.1")

Как правило, программы пишутся на С и компилируются clang (поддержка EBPF ожидается также в GCC 10). Пример:

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

Чего делать не следует

Вредить источнику атаки

Не нужно слать обратные пакеты с целью повредить источник атаки. Во-первых, источником может быть не злоумышленник, а уязвимый сервер (reflection attack), и вред будет невинным людям. Во-вторых, написание вредоносных программ является преступлением в большинстве стран.

Пытаться обойти ограничения API

Программируемый фильтр — новая и мощная контрмера. Некоторых возможностей специально нет, чтобы нельзя было повредить сети. Другие могут временно отсутствовать — обратитесь с идеей к разработчикам.

Особенности EBPF в MITIGATOR

Недоступны заголовки ниже сетевого уровня

Это ограничение введено, потому что программы работают в политиках защиты, где заголовки Ethernet и VLAN не требуется анализировать (это делает MITIGATOR), а с другой стороны, менять их было бы опасно для сети, где развернут MITIGATOR.

Не поддерживаются аргументы типа BPF_ABS и BPF_IND

Эти аргументы поддерживает ядро Linux для доступа к данным пакета. Актуально только при переписывании cBPF в EBPF на ассемблере. Функции, которые можно использовать взамен:

  • packet_network_header() — указатель на данные, начиная с заголовка L3;
  • packet_transport_payload() — указатель на полезную нагрузку TCP/UDP.