Ниже приведён набор сниппетов для настройки WireGuard для трёх разных дистрибутивов Linux и для FreeBSD.
Предполагается, что сервер будет на Debian, сеть 10.9.21.0/24.

Сервер, Debian

apt install wireguard-tools
nano /etc/network/interfaces.d/wg0

auto wg0
iface wg0 inet static
    address 10.9.21.1/32
    pre-up ip link add wg0 type wireguard
    pre-up wg setconf wg0 /etc/wireguard/wg0.conf
    up ip -4 route add 10.9.21.0/24 dev wg0
    # up /bin/systemctl restart sshd.service
    post-down ip link del wg0

umask 077
cd /etc/wireguard/
wg genkey > server-private.key
wg pubkey < server-private.key > server-public.key

nano /etc/wireguard/wg0.conf

[Interface]
ListenPort = 1234
PrivateKey = <server-private.key>

[Peer]
# Debian client
PublicKey = <public.key>
AllowedIPs = 10.9.21.3/32

[Peer]
# CentOS client
PublicKey = <public.key>
AllowedIPs = 10.9.21.4/32

[Peer]
# Ubuntu client
PublicKey = <public.key>
AllowedIPs = 10.9.21.5/32

[Peer]
# FreeBSD client
PublicKey = <public.key>
AllowedIPs = 10.9.21.6/32

Хорошее пополнение коллекции.
Новостям надо дать настояться, после чего смаковать детали.

• Red Hat, RED HAT, КАРЛ!
• GitHub Actions, как обычно.
• NPM, к этому уже привыкли.
• Arch User Repository, уже интересней.

Пересоберём 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

Прошло всего-навсего пол года, но новостная лента не переставала приносить новые забавные уязвимости.
Как обычно, я не акцентирую внимание на системных уязвимостях в snapd / Rust Coreutils / Flatpak, ядре (Copy Fail, Dirty Frag, Fragnesia, pidfd, PinTheft, GRO Frag) или AppArmor.

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

Мне гораздо интереснее следить за внедрениями вредоносного кода в системы распространения пакетов, библиотеки и прочие репозитории.

Потому что это относится к “активным” и непосредственным атакам, им почти не надо сочетания определённых факторов, после загрузки они сразу же поразят репозиторий разработчика, далее соберут его персональную/финансовую/авторизационную информацию, а после этого продолжат действовать по цепочке на всех серверах, к которым у него был доступ.

Продолжая предыдущие скучные опусы на тему изоляции окружений, самое время вспомнить про wayland.
Конечно же, это не призыв к действию, а просто примеры и размышления.
Сам я придерживаюсь философии, где центр системы это пользователь, и он в праве настраивать всё так, как он считает нужным, а не так как это навязывается общими тенденциями, или как это реализовано в конкретном дистрибутиве, вместе с этим понимая и принимая все риски и последствия этих действий.
Как говорится, “If you know what you are doing”.

И прежде чем приступить, опять стоит написать, что:

• Да, я понимаю, что это всё очень поверхностно.
• Да, никакие подключения к локальной графической оболочке не допустимы для чего-то опасного, и надо использовать vnc или virt-viewer/spice.
• Непривилегированный LXC надо заменить на Xen / KVM
• И да, я знаю, что из KVM изоляции тоже можно выйти.
• И про Flatpak я тоже знаю.
• И, наконец, да, я знаю о Qubes OS и её архитектуре, можно сказать, с момента её появления, а это 2010 год.

И, несколько упрощая и адаптируя идеи QubesOS под свои повседневные задачи, я предпочитаю в основном использовать или других локальных пользователей, или достаточно легковесные окружения LXC.

И да, в них я запускаю не что-то потенциально опасное, а то, что многие из вас используют непосредственно под своим аккаунтом в системе, например:

• Firefox для повседневного использования и просмотра “чего попало”.
• Несколько проектов использующих пакеты из PyPI, RubyGems.
• Отдельно то, что я собираю из исходников с того же GitHub.
• Сторонние программы element-desktop, Telegram, Zoom.