Перезберемо Nginx з патчем CVE-2026-9256 відповідно до Debian-way.

Критична вразливість у nginx, що дозволяє віддалено досягти виконання коду з правами робочого процесу nginx через відправлення спеціально оформленого HTTP-запиту.
Але не у цьому річ.
А річ у тому, що мейнтейнери Debian не квапляться викочувати новий пакет із патчами.

• Security Bug Tracker CVE-2026-9256
• NGINX ngx_http_rewrite_module vulnerability CVE-2026-9256

apt --no-install-recommends \
    --no-install-suggests install \
    build-essential \
    fakeroot \
    devscripts

nano /etc/apt/sources.list

# trixie sources
deb-src https://deb.debian.org/debian/ trixie main contrib non-free non-free-firmware
deb-src http://security.debian.org/debian-security/ trixie-security main contrib non-free non-free-firmware
deb-src https://deb.debian.org/debian/ trixie-updates main contrib non-free non-free-firmware

Вступ здалеку

Нещодавно знову ностальгував у FreeBSD, все чудово, все звично, все зручно.
Лише один момент повністю виключає її з використання, принаймні в мене.
Майже на всіх моїх ноутбуках FreeBSD не підтримує ні режим сну, ні режим очікування (s2ram/s2disk).
І зробити я з цим нічого не зміг, а перепробував багато чого.

Без режиму очікування абсолютно неможливо користуватися ноутбуком, так як після транспортування необхідно по новому все завантажувати, включати, відкривати.
Та й перезавантажую робочі станції лише після оновлень, які цього вимагають.

З багатьох приємних дрібниць, які є у Фряхі, і які відсутні в Debian це ZFS Boot Environments, що зручніше, ніж, скажімо, снапшоти LVM.
А друге це GEOM_ELI, який підтримує не лише, як LUKS, режим АБО пароль, АБО ключ, але також підтримує режим І пароль, І ключ.

Подумав, подумав, та й вирішив розгорнути Debian з нуля з урахуванням усіх інструментів, які використовую, досвіду, і, що важливо, звичок.

Debian поки що залишається основною моєю системою, тому єдиний спосіб отримання хардварного (фізичного) ключа шифрування на додаток до паролю - це зробити його з хедера і розмістити на USB-флешці.

Дуже, дуже часто доводиться стикатися з необхідністю використання певної версії Пітона, наприклад, для torch, або чогось специфічного.
Використовувати conda або Docker у зв’язці з nvidia-container-toolkit і потім налаштовувати образи наприклад nvidia/cuda:13.0.1-runtime-ubuntu22.04 мені відчувається протиприродно, хоча часто так робив.
Та й у контейнері доводиться встановлювати додаткові пакети.

Простіше і зручніше зібрати все на хостовій системі, але при цьому не допустити контамінації всієї системи сторонніми бібліотеками та файлами.

Далі наводиться приклад компіляції кількох версій Python тільки для групи verpy, що дещо зручніше, ніж встановлення лише для одного користувача.

• ai - довільний користувач, від якого здійснюється компіляція.
• verpy - група, якою буде дозволено використання.

apt install \
    build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev \
    wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev \
    liblzma-dev libgdbm-dev libnsl-dev libgdbm-compat-dev

mkdir /opt/openssl
mkdir /opt/python
groupadd --gid 42398 verpy
usermod -aG verpy ai

У цьому прикладі показана установка поверх LXC, тоді як для будь-якого більш-менш серйозного застосування це абсолютно неприйнятно і вимагає використання KVM з додатковими заходами безпеки.
І, крім того, встановлення на KVM буде набагато, набагато простіше.
LXC не забезпечує адекватної безпеки, оскільки для правильної роботи потрібне монтування розділів /sys та /proc з хоста, які доступні всім примірникам LXC.
Крім того, цей приклад потребує використання привілейованого контейнера LXC.
Однак LXC дозволяє легко налаштувати тестову інфраструктуру без накладних витрат, пов’язаних з KVM.
Тому деякі аспекти в цьому прикладі будуть пов’язані виключно з налаштуванням в LXC.

Хост

Спочатку давайте підготуємо хост-систему.

nano /etc/modules

overlay
nf_nat
br_netfilter
xt_conntrack
rbd
fuse
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
iptable_nat

nano /etc/sysctl.d/35-lxc-kubernetes.conf

kernel.dmesg_restrict = 0
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1
net.bridge.bridge-nf-call-iptables = 1
# --conntrack-max-per-core Default: 32768 * N
net.netfilter.nf_conntrack_max=131072
# net.bridge.bridge-nf-call-arptables
# kernel.pid_max=100000
# user.max_user_namespaces=15000
vm.compact_memory = 1
vm.overcommit_memory = 1

Усі знають про ліміти кількості підключень з одного IP (IP-based), але що робити, якщо ми хочемо обмежити кількість підключень до деякого API на один токен авторизації?
І не важливо, скільки різних IP буде використано.

Частина конфігу nginx:

map $request_uri $client_token {
    "~*(?i)(token=)([a-f0-9]{32})" $2;      # regex return <32str>
    default                        "";      # Fallback to limit_req_zone:global
}

limit_req_zone  $binary_remote_addr   zone=global:32m       rate=100r/s;    # Rule_1
limit_req_zone  $client_token         zone=tokenlimit:32m   rate=5r/s;      # Rule_2
limit_req       zone=global           burst=25;

server {
        location / {
            index index.html;
            root /var/www/html;
        }
        location = /api {
            index index.html;
            root /var/www/api/html;
            limit_req   zone=tokenlimit   burst=5 nodelay;  # api location
            limit_req   zone=global;                        # Fallback
            limit_req_status              429;              # 503