Объявление

**DOMINUS_EDEM** · 30-10-2019, 10:17

Постановка задачи

Перейдем к заявленной задачи: написать на XDP механизм SYN cookies.

До сих пор популярной DDoS-атакой остается SYN flood, суть которой в следующем. При установке соединения (TCP handshake) сервер получает SYN, выделяет ресурсы под будущее соединение, отвечает SYNACK-пакетом и ожидает ACK. Атакующий просто отправляет SYN-пакеты с поддельных адресов в количестве тысяч в секунду с каждого хоста из многотысячного ботнета. Сервер вынужден выделять ресурсы сразу по прибытии пакета, а освобождает по большому таймауту, в результате исчерпывается память или лимиты, новые соединения не принимаются, сервис недоступен.

Если не выделять по SYN-пакету ресурсы, а только отвечать SYNACK-пакетом, как тогда серверу понять, что ACK-пакет, пришедший позже, относится к SYN-пакету, который не сохраняли? Ведь атакующий может генерировать и фальшивые ACK. Суть SYN cookie в том, чтобы кодировать в seqnum параметры соединения как хэш от адресов, портов и меняющейся соли. Если ACK успел прийти до смены соли, можно еще раз посчитать хэш и сравнить с acknum. Подделать acknum атакующий не может, так как соль включает секрет, а перебрать не успеет из-за ограниченного канала.

SYN cookie давно реализован в ядре Linux и даже может автоматически включаться, если SYN приходят слишком быстро и массово.

С точки зрения пакетов, XDP-программа должна делать следующее:

на SYN отвечать SYNACK с cookie;
на ACK отвечать RST (разрывать соединение);
остальные пакеты сбрасывать.

Псевдокод алгоритма вместе с разбором пакета:

Код:

Если это не Ethernet,
    пропустить пакет.
Если это не IPv4,
    пропустить пакет.
Если адрес в таблице проверенных,               (*)
        уменьшить счетчик оставшихся проверок,
        пропустить пакет.
Если это не TCP,
    сбросить пакет.     (**)
Если это SYN,
    ответить SYN-ACK с cookie.
Если это ACK,
    если в acknum лежит не cookie,
        сбросить пакет.
    Занести в таблицу адрес с N оставшихся проверок.    (*)
    Ответить RST.   (**)
В остальных случаях сбросить пакет.

Одной (*) отмечены пункты, в которых нужно управлять состоянием системы — на первом этапе можно обойтись без них, просто реализовав TCP handshake с генерацией SYN cookie в качестве seqnum.

На месте (**), пока у нас нет таблицы, будем пропускать пакет.

Реализация TCP handshake

Разбор пакета и верификация кода

Нам понадобятся структуры сетевых заголовков: Ethernet (uapi/linux/if_ether.h), IPv4 (uapi/linux/ip.h) и TCP (uapi/linux/tcp.h). Последний у меня так и не получилось подключить из-за ошибок, связанных с atomic64_t, пришлось скопировать нужные определения в код.

Все функции, которые в C выделяются для удобства чтения, должны быть встроены по месту вызова, так как верификатор eBPF в ядре запрещает переходы назад, то есть, фактически, циклы и вызовы функций.

Код:

#define INTERNAL static __attribute__((always_inline))

Макрос LOG() отключает печать в релизной сборке.

Программа представляет собой конвейер из функций. Каждая принимает пакет, в котором выделен заголовок соответствующего уровня, например, process_ether() ожидает, что заполнено ether. По результатам анализа полей функция может передать пакет на уровень выше. Результат работы функции — действие XDP. Пока обработчики SYN и ACK пропускают все пакеты.

Код:

struct Packet {
    struct xdp_md* ctx;

    struct et**dr* ether;
    struct iphdr* ip;
    struct tcphdr* tcp;
};

INTERNAL int process_tcp_syn(struct Packet* packet) { return XDP_PASS; }
INTERNAL int process_tcp_ack(struct Packet* packet) { return XDP_PASS; }
INTERNAL int process_tcp(struct Packet* packet) { ... }
INTERNAL int process_ip(struct Packet* packet) { ... }

INTERNAL int
process_ether(struct Packet* packet) {
    struct et**dr* ether = packet->ether;

    LOG("Ether(proto=0x%x)", bpf_ntohs(ether->h_proto));

    if (ether->h_proto != bpf_ntohs(ETH_P_IP)) {
        return XDP_PASS;
    }

    // B
    struct iphdr* ip = (struct iphdr*)(ether + 1);
    if ((void*)(ip + 1) > (void*)packet->ctx->data_end) {
        return XDP_DROP; /* malformed packet */
    }

    packet->ip = ip;
    return process_ip(packet);
}

SEC("prog")
int xdp_main(struct xdp_md* ctx) {
    struct Packet packet;
    packet.ctx = ctx;

    // A
    struct et**dr* ether = (struct et**dr*)(void*)ctx->data;
    if ((void*)(ether + 1) > (void*)ctx->data_end) {
        return XDP_PASS;
    }

    packet.ether = ether;
    return process_ether(&packet);
}

Обращаю внимание на проверки, отмеченные A и B. Если закомментировать A, программа соберется, но при загрузке будет ошибка верификации:

Код:

Verifier analysis:

<...>
11: (7b) *(u64 *)(r10 -48) = r1
12: (71) r3 = *(u8 *)(r7 +13)
invalid access to packet, off=13 size=1, R7(id=0,off=0,r=0)
R7 offset is outside of the packet
processed 11 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0

Error fetching program/map!

Ключевая строка invalid access to packet, off=13 size=1, R7(id=0,off=0,r=0): есть пути выполнения, когда тринадцатый байт от начала буфера находится вне пакета. По листингу сложновато понять, о какой строке идет речь, зато есть номер инструкции (12) и дизассемблер, показывающий строки исходного кода:

Код:

llvm-objdump -S xdp_filter.o | less

В данном случае он указывает на строку

Код:

LOG("Ether(proto=0x%x)", bpf_ntohs(ether->h_proto));

по которой понятно, что проблема в ether. Всегда бы так.

Ответ на SYN

Цель на этом этапе — формировать корректный SYNACK-пакет с фиксированным seqnum, который в будущем заменится на SYN cookie. Все изменения происходят в process_tcp_syn() и окрестностях.

Проверка пакета

Как ни странно, вот самая примечательная строка, точнее, комментарий к ней:

Код:

/* Required to verify checksum calculation */
const void* data_end = (const void*)ctx->data_end;

При написании первой версии кода использовалось ядро 5.1, для верификатора которого была разница между data_end и (const void*)ctx->data_end. При написании статьи ядро 5.3.1 не имело такой проблемы. Возможно, компилятор обращался к локальной переменной иначе, чем к полю. Мораль — на большой вложенности упрощение кода может помочь.

Далее рутинные проверки длин во славу верификатора; о MAX_CSUM_BYTES ниже.

Код:

const u32 ip_len = ip->ihl * 4;
if ((void*)ip + ip_len > data_end) {
    return XDP_DROP; /* malformed packet */
}
if (ip_len > MAX_CSUM_BYTES) {
    return XDP_ABORTED; /* implementation limitation */
}

const u32 tcp_len = tcp->doff * 4;
if ((void*)tcp + tcp_len > (void*)ctx->data_end) {
    return XDP_DROP; /* malformed packet */
}
if (tcp_len > MAX_CSUM_BYTES) {
    return XDP_ABORTED; /* implementation limitation */
}

Разворот пакета

Заполняем seqnum и acknum, выставляем ACK (SYN уже выставлен):

Код:

const u32 cookie = 42;
tcp->ack_seq = bpf_htonl(bpf_ntohl(tcp->seq) + 1);
tcp->seq = bpf_htonl(cookie);
tcp->ack = 1;

Меняем местами порты TCP, адрес IP и MAC-адреса. Стандартная библиотека недоступна из XDP-программы, поэтому memcpy() — макрос, скрывающий интринсик Clang.

Код:

const u16 temp_port = tcp->source;
tcp->source = tcp->dest;
tcp->dest = temp_port;

const u32 temp_ip = ip->saddr;
ip->saddr = ip->daddr;
ip->daddr = temp_ip;

struct et**dr temp_ether = *ether;
memcpy(ether->h_dest, temp_ether.h_source, ETH_ALEN);
memcpy(ether->h_source, temp_ether.h_dest, ETH_ALEN);

Пересчет контрольных сумм

Контрольные суммы IPv4 и TCP требуют сложения всех 16-битных слов в заголовках, а размер заголовков записан в них, то есть на момент компиляции неизвестен. Это проблема, потому что верификатор не пропустит обычный цикл до переменной границы. Зато размер заголовков ограничен: до 64 байтов каждый. Можно сделать цикл с фиксированным количеством итераций, который может закончиться досрочно.

Замечу, что есть RFC 1624 про то, как пересчитывать контрольную сумму частично, если изменены только фиксированные слова пакетов. Однако способ не универсальный, а реализацию было бы сложнее поддерживать.

Функция расчета контрольной суммы:

Код:

#define MAX_CSUM_WORDS 32
#define MAX_CSUM_BYTES (MAX_CSUM_WORDS * 2)

INTERNAL u32
sum16(const void* data, u32 size, const void* data_end) {
    u32 s = 0;
#pragma unroll
    for (u32 i = 0; i < MAX_CSUM_WORDS; i++) {
        if (2*i >= size) {
            return s; /* normal exit */
        }
        if (data + 2*i + 1 + 1 > data_end) {
            return 0; /* should be unreachable */
        }
        s += ((const u16*)data)[i];
    }
    return s;
}

Несмотря на то, что size проверено вызывающим кодом, второе условие выхода необходимо, чтобы верификатор мог доказать завершение цикла.

Для 32-битных слов реализована более простая версия:

Код:

INTERNAL u32
sum16_32(u32 v) {
    return (v >> 16) + (v & 0xffff);
}

Собственно пересчет контрольных сумм и отправка пакета обратно:

Код:

ip->check = 0;
ip->check = carry(sum16(ip, ip_len, data_end));

u32 tcp_csum = 0;
tcp_csum += sum16_32(ip->saddr);
tcp_csum += sum16_32(ip->daddr);
tcp_csum += 0x0600;
tcp_csum += tcp_len << 8;
tcp->check = 0;
tcp_csum += sum16(tcp, tcp_len, data_end);
tcp->check = carry(tcp_csum);

return XDP_TX;

Функция carry() делает из 32-битной суммы 16-битных слов контрольную сумму, согласно RFC 791.

Проверка рукопожатия TCP

Фильтр корректно устанавливает соединение с netcat, пропуская финальный ACK, на который Linux отвечал RST-пакетом, так как сетевой стек не получал SYN — он был переделан в SYNACK и отправлен обратно - и с точки зрения ОС прибыл пакет, не относящийся к открытым соединениям.

Код:

$ sudo ip netns exec xdp-test   nc -nv 192.0.2.1 6666
192.0.2.1 6666: Connection reset by peer

Важно проверять именно полноценными приложениями и наблюдать tcpdump на xdp-remote потому что, например, hping3 не реагирует на некорректные контрольные суммы.

SYN cookie

С точки зрения XDP сама проверка тривиальна. Алгоритм расчета примитивный и, вероятно, уязвимый для изощренного злоумышленника. Ядро Linux, например, использует криптографический SipHash, но его реализация для XDP явно выходит за рамки статьи.

Появилось для новых TODO, связанных со внешним взаимодействием:

XDP-программа не может хранить cookie_seed (секретную часть соли) в глобальной переменной, нужно хранилище в ядре, значение в котором будет периодически обновляться из надежного генератора.
При совпадении SYN cookie в ACK-пакете нужно не печатать сообщение, а запоминать IP проверенного клиента, чтобы далее пропускать пакетыот него.

Проверка легитимным клиентом:

Код:

$ sudoip netns exec xdp-test   nc -nv 192.0.2.1 6666
192.0.2.1 6666: Connection reset by peer

В логах зафиксировано прохождение проверки (flags=0x2 — это SYN, flags=0x10 — это ACK):

Код:

Ether(proto=0x800)
  IP(src=0x20e6e11a dst=0x20e6e11e proto=6)
    TCP(sport=50836 dport=6666 flags=0x2)
Ether(proto=0x800)
  IP(src=0xfe2cb11a dst=0xfe2cb11e proto=6)
    TCP(sport=50836 dport=6666 flags=0x10)
      cookie matches for client 20200c0

Пока нет списка проверенных IP, защиты от собственно SYN flood не будет, но вот реакция на ACK flood, запускаемый такой командой:

Код:

sudo ip netns exec xdp-test   hping3 --flood -A -s 1111 -p 2222 192.0.2.1

Записи в логе:

Код:

Ether(proto=0x800)
  IP(src=0x15bd11a dst=0x15bd11e proto=6)
    TCP(sport=3236 dport=2222 flags=0x10)
      cookie mismatch

Заключение

Иногда eBPF вообще и XDP в частности представляется скорее как инструмент продвинутого администратора, нежели как платформа для разработки. Действительно, XDP — инструмент вмешательства в обработку пакетов ядром, а не альтернатива ядерному стеку, как DPDK и прочие варианты kernel bypass. С другой стороны, XDP позволяет реализовать довольно сложную логику, которую, к тому же, легко обновлять без паузы в обработке трафика. Верификатор не создает больших проблем, лично я не отказался бы от такого для частей userspace-кода.

Во второй части, если тема интересна, доделаем таблицу проверенных клиентов и разрыв соединений, внедрим счетчики и напишем userspace-утилиту для управления фильтром.

**МЕНДЕЛЕЕВ** · 04-11-2019, 12:40

Тупо спизжено с одного сайта

Объявление

Пишем защиту от DDoS-атак на XDP. Ядерная часть

Пишем защиту от DDoS-атак на XDP. Ядерная часть

Комментарий

Комментарий