Hacker News Digest

XDP (eXpress Data Path) — самый быстрый фреймворк для обработки пакетов в Linux, но изначально работал только для входящего трафика. Компания Loophole Labs обнаружила лазейку, позволяющую использовать XDP для исходящего трафика, exploiting уязвимость в том, как ядро Linux определяет направление пакета. Их решение обеспечивает в 10 раз лучшую производительность, чем текущие альтернативы, работает с существующими Docker/Kubernetes контейнерами и не требует модификаций ядра.

При обработке трафика со скоростью сотни гигабит в секунду во время миграции контейнеров и ВМ, XDP достигает скорости линии связи (line-rate), в то время как Traffic Control (TC) ограничен всего 21Gbps на исходящем трафике. Это критически важно для их инфраструктуры, где каждая CPU-единица имеет значение. Решение позволяет обрабатывать пакеты на максимальной скорости сетевого интерфейса, будь то 20Gbps или 200Gbps, без каких-либо изменений в существующей инфраструктуре.

• XDP для egress – авторы используют виртуальные интерфейсы veth, чтобы заставить XDP обрабатывать исходящий трафик, что позволяет достичь 10-кратного прироста пропускной способности по сравнению с iptables/TC, при этом оставаясь совместимым с контейнерами и Kubernetes.
• производительность и совместимость – тесты показывают, что при использовании XDP для обработки исходящих пакетов достигается 20-ти кратное увеличение пропускной способности по сравнению с iptables/TC, при этом не требуется никаких изменений в контейнере или оркестраторе.
• почему не DPDK? – авторы отмечают, что DPDK требует специального драйвера и не может быть использован в контейнерах без привилегий, в то время как XDP работает в любом месте, где работает Linux kernel, и не требует специального оборудования.
• будущее: TC и eBPF – вместо того, чтобы продолжать использовать устаревший TC, сообщество может перейти на eBPF, что позволит в будущем использовать более продвинутые функции, такие как socket фильтры, которые могут быть реализованы в пространстве имен.

Автор использует технологию XDP (Express Data Path) для высокопроизводительной фильтрации сетевых пакетов прямо на уровне сетевого устройства, что позволяет обрабатывать до 26 миллионов запросов в секунду на потребительском оборудовании. XDP работает поверх eBPF — виртуальной машины в ядре Linux, где код компилируется в низкоуровневые инструкции для быстрой проверки пакетов с гарантиями безопасности, например, предотвращения чтения за пределами буфера.

Для идентификации клиентов, особенно скриптовых инструментов вроде curl, применяется TLS-фингерпринтинг по стандарту JA4. Этот метод анализирует параметры TLS-рукопожатия (версии, шифры, расширения), формируя уникальный отпечаток, который можно сопоставить с конкретным ПО. Хотя расчёт хэша SHA256 напрямую в eBPF сложен, сама возможность такой фильтрации на уровне ядра позволяет эффективно блокировать массовые автоматизированные запросы с минимальными затратами ресурсов.

• Обход TLS-отпечатков (JA3/JA4) возможен через случайный подбор шифров в curl или инструменты вроде curl-impersonate
• Многие системы защиты (например, Anubis) сознательно разрешают запросы от curl и Googlebot, чтобы отсеивать только злоумышленников
• Эффективная блокировка требует комбинации методов: отпечатки TLS, IP-адреса, ASN, HTTP-фингерпринтинг и JavaScript-вызовы
• Мотивированные скрейперы используют продвинутые техники: эмуляцию браузера, вращение отпечатков и прокси
• Борьба со скрейпингом — это "гонка вооружений", ведущая к росту затрат для обеих сторон и рискующая навредить открытости интернета

PythonBPF – пишем eBPF-программы на чистом Python
(в 2 раза короче)

---

Что это
Библиотека pip install pythonbpf компилирует Python-код в объектные .o-файлы и загружает их в ядро как обычные eBPF-программы. Репо: GitHub.

---

Было
Встраивали C в многострочные строки, теряя линтеры и подсветку:

from bcc import BPF
prog = """
int hello(void *ctx) {
    bpf_trace_printk("Hello\\n");
    return 0;
}
"""
b = BPF(text=prog)
b.attach_kprobe(event="sys_clone", fn_name="hello")

---

Стало
Тот же функционал — на Python:

from pythonbpf import bpf, section, compile
from pythonbpf.maps import HashMap
from pythonbpf.helpers import ktime
from ctypes import *

@bpf
def last() -> HashMap:          # глобальная BPF-мапа
    return HashMap(c_uint64, c_uint64, 1)

@bpf
@section("tracepoint/syscalls/sys_enter_execve")
def hello(_: c_void_p) -> c_int32:
    print("entered")
    return 0

@bpf
@section("tracepoint/syscalls/sys_exit_execve")
def bye(_: c_void_p) -> c_int64:
    print("exited")
    last().update(0, ktime())
    return 0

@bpf
def LICENSE() -> str:           # лицензия ядра
    return "GPL"

compile()                       # → .o и загрузка

---

Как работает

1. ast → дерево
2. llvmlite → LLVM IR
3. llc → BPF-объект
4. libbpf → загрузка в ядро

• Участники обсуждают инструмент для компиляции Python в eBPF байт-код, который был создан как проект на хакатоне и пока считается «игрушечным».
• Подчеркивается, что использование LLVM для трансляции в eBPF — более перспективный подход, чем прямое преобразование Python-байткода.
• Несколько пользователей отмечают отсутствие четких объяснений, что такое eBPF, и предлагают добавить больше документации и примеров.
• Критикуется идея использования LLM (больших языковых моделей) для генерации eBPF-кода из-за строгой проверки и специфики eBPF.
• Упоминаются существующие аналогичные проекты для других языков (Java, Node.js) и инструменты из мира BCC.
• Автор проекта признает, что код находится на ранней стадии и требует значительной доработки.

ProcMon-for-Linux — порт утилиты Sysinternals Process Monitor для Linux.
Позволяет в реальном времени наблюдать за системными вызовами (open, read, write, fork, exec и др.) и событиями ядра, фильтровать, сохранять и анализировать трейсы.

Ключевые возможности

• CLI-интерфейс, знакомые фильтры pid, process, operation, path, result.
• Форматы вывода: консоль, XML, CSV, JSON.
• Поддержка x86_64, ARM64; ядро ≥ 4.9.
• Сборка: cmake, libsqlite3-dev, libncurses5-dev, libssl-dev, bcc-dev.

Установка

Ubuntu 20.04+

sudo apt install procmon

Или из исходников:

git clone https://github.com/microsoft/ProcMon-for-Linux
cd ProcMon-for-Linux
mkdir build && cd build
cmake ..
make
sudo make install

Быстрый старт

# отслеживать процесс firefox
sudo procmon -p $(pgrep firefox)

# сохранить лог в JSON
sudo procmon -p 1234 -o trace.json -f json

Лицензия

MIT.

• Пользователи обсуждают ProcMon для Linux: кто-то рад, что не придётся опрашивать /proc, кто-то сомневается в целях проекта и его отличии от htop+strace.
• Интересуются совместимостью вывода с Windows-версией и поддержкой телеметрии, а также жалуются на старый INSTALL.md и ограниченные требования (Ubuntu 18.04).
• Некоторые считают утилиту TUI-обёрткой над strace, другие подчеркивают, что она использует eBPF и может следить за всеми процессами без замедления.
• Поднимаются темы «почему нужны сразу GCC и Clang» и «Microsoft всё больше делает инструменты для Linux».