Лига сисадминов

Как пакет проходит через ядро Linux

Большинство инженеров знают: XDP - это быстро, а nftables - «та самая штука-файрвол». Но мало кто понимает, почему под нагрузкой они ведут себя так по-разному. Ответ не в инструментах, а в том, где в ядре каждый из них работает.

Чтобы рассуждать о том, куда вешать хук, об ошибках верификатора, дизайне map или о скорости обработки пакетов, вам нужна одна вещь: ясная картина того, как пакет на самом деле идёт через ядро Linux.

Этот пост про то, как такую картину собрать.


https://telegra.ph/Kak-paket-prohodit-cherez-yadro-Linux-10-04

#ит_статьи #linux #ebpf #xdp #netfilter #skb #network

Docker Compose: тюнинг контейнеров с помощью ulimits и shm_size

Лимиты CPU и памяти обычно покрывают очевидные ресурсы. Но еще две опции решают специфические задачи: ulimits - для лимитов ядра и shm_size - для разделяемой памяти.

https://telegra.ph/Docker-Compose-tyuning-kontejnerov-s-pomoshchyu-ulimits-i-shm-size-10-03

#ит_статьи #devops #linux #docker #docker_compose #containers

Trynix - тестируем классические Linux-утилиты, ничего не устанавливая

Хотите проверить кое-что в старой версии Python, скажем, в той, что из 2017 года, просто чтобы понять, оттуда ли баг, за которым вы охотитесь. Обычно это значит разыскивать Docker-образ или старый бинарник Python, чтобы прогнать свои тесты. А с trynix кликаете по ссылке, и хоп, у вас shell с вашей утилитой.

Сайт сделан Farid Zakaria, который годами ковыряется с Nix и называет это своим "magnum opus". В общем, прямо в вашей вкладке поднимается машина Linux x86_64, и запрошенный пакет уже лежит в PATH. Ничего ставить не надо, аккаунт создавать не надо, и всё работает прямо в браузере.

Я попробовал сегодня утром python3 версии 3.6.2. Браузер идёт за путями store, проверяет подписи, и секунд через тридцать появляется prompt. Набираю python3 --version, а он отвечает: Python 3.6.2, с glibc 2.25 и тогдашним OpenSSL 1.0.2l в комплекте. Вот так у меня и оказался Python 2017 года в Chrome 2026-го, и свою машину я вообще не трогал.

https://telegra.ph/Trynix---testiruem-klassicheskie-Linux-utility-nichego-ne-ustanavlivaya-10-01

#ит_статьи #linux #nix #qemu #shell #trynix

Seccomp в K8s 3/3: измеряем, оцениваем и масштабируем

Я уже который пост описываю одну и ту же сквозную мысль: можно часами собирать seccomp-профили ручной выделки и говорить, что все стало безопаснее, но сами по себе мы этого не знаем. Мы просто предполагаем. И даже когда мы хотим измерить, «хороший» ли конкретный seccomp-профиль, прийти к этому решению - та еще сложность.

Например, чтобы решить, «хороший» ли seccomp-профиль, у нас есть 1 простой вопрос:

Какие системные вызовы он разрешает, а какие блокирует?

Чтобы получить этот ответ, приходится задать еще вопросы:
- Что будет на другой архитектуре?
- Что будет, если процессу выдали определенный capability?
- Есть ли способы обойти нашу seccomp-политику через мультиплексирование?
- Чем отличаются рантаймы контейнеров?

По-моему, отсутствие данных на уровне популяции - реально одна из самых больших проблем в этой теме прямо сейчас. Мы все подкручиваем профили вслепую. Вот чего у нас нет: публичных данных о том, какие seccomp-профили организации реально выкатывают. Мы можем посчитать скор вашего профиля относительно дефолта Docker, но не можем сказать, как вы смотритесь на фоне индустрии, потому что никто свои профили не публикует. А зачем им?

https://telegra.ph/Seccomp-v-K8s-33-izmeryaem-ocenivaem-i-masshtabiruem-10-01

#ит_статьи #devops #kubernetes #linux #seccomp #syscall #containers

Seccomp в K8s 2/3: обходы и брейкауты

В другом посте я в основном описывал операционную нагрузку от ведения seccomp-профилей и описывал сценарии, где профиль может быть не таким эффективным, как мы думаем. Это тот пост, где я хотел вернуться к взгляду атакующего. У вас есть контейнер. Seccomp включён. Профиль выглядит разумно - нет bpf, нет ptrace, сетевые syscalls ограничены. Что делаем?

Пока я собирал это исследование, я понял, что есть немало ситуаций, где seccomp-фильтр можно обойти. Они делятся на несколько категорий:
- Путаница с архитектурами - вызов заблокированных syscalls через альтернативные ABI или архитектуры CPU, на которые вы не рассчитывали (разбирать не буду: либо очевидно, либо митигация уже есть)
- Кривая настройка профиля - seccomp технически активен, но профиль разрешает больше, чем задумывалось (режим privileged, загрязнение наследованием от runtime, опасные правила, завязанные на capabilities)
- Семантика применения - злоупотребление разницей между SCMP_ACT_KILL (поток) и SCMP_ACT_KILL_PROCESS, или SCMP_ACT_LOG, чтобы прощупать фильтр и не умереть
- Мультиплексирование syscalls - один разрешённый syscall делает работу многих заблокированных.

Дальше поговорим про мультиплексирование. Давайте встанем на место атакующего, у которого RCE в окружении. Давайте даже допустим, что контейнер запущен с CAP ADD ALL, ему выданы все capabilities, и по факту это уже не контейнер. И посмотрим, сможем ли мы обойти seccomp.

https://telegra.ph/Seccomp-v-K8s-23-obhody-i-brejkauty-09-30

#ит_статьи #devops #kubernetes #linux #seccomp #syscall #containers

Seccomp в K8s 1/3: собираем небезопасные и неполные профили

Идея seccomp-профиля для контейнера простая: ваш контейнер делает хорошие системные вызовы, давайте заблокируем плохие. Записываете системные вызовы, которые делает ваш контейнер, собираете JSON-профиль seccomp, который разрешает только их, и всё, чего ваше приложение не вызывало, блокируется. Минимальная поверхность атаки. Идеально. Мы свою работу сделали?
Оказывается, сгенерировать такие профили легко, но сгенерировать их точно сложно. Многие из вас видели инструмент, который обещает сам собрать вам seccomp-профили. И они работают! Но как для таких инструментов выглядит «хорошо»? Они точные? Они собирают безопасные профили? Они вообще хоть как-то снижают риск?

Вот инструменты, которые я проверял:
- Inspektor Gadget: отличный опенсорсный инструмент на eBPF, сейчас принадлежит Microsoft
- Tracee: инструмент от Aqua, который трассирует системные вызовы разными способами и оценивает кластер
- kubectl-trace: eBPF-инструмент, который в основном отдаёт вам сырые события системных вызовов на ноде. (Для этого не идеален, но пытается доказать мысль).
Каждый инструмент я запустил в VM с Minikube, настроил набор Pod'ов Kubernetes на запуск и попросил инструмент записать системные вызовы именно этого Pod'а.

Результаты получились интересные.

https://telegra.ph/Seccomp-v-K8s-13-sobiraem-nebezopasnye-i-nepolnye-profili-09-29

#ит_статьи #devops #kubernetes #linux #seccomp #syscall #containers

Проверка целостности PAM-модулей: обнаружение бэкдоров вроде PamDOORa

Каждый логин, каждая команда sudo, каждая SSH-сессия на Linux-хосте проходит через PAM, фреймворк Pluggable Authentication Modules. Устройство PAM - его сила и его уязвимость разом. Хватает положить разделяемую библиотеку в /lib/security/ и дописать одну строку в файл из /etc/pam.d/, чтобы перехватить весь стек аутентификации. Модуль работает с привилегиями вызывающего процесса. Для SSH и sudo это root.

В мае 2026 на киберпреступном форуме Rehub появился постэксплуатационный тулкит PamDOORa с заявленной ценой $1600. Закрепляется он скомпилированной разделяемой библиотекой PAM. Атакующий, который ненадолго получил root (эксплойт ядра, украденный привилегированный креденшел или побег из контейнера), кладет модуль в /lib/security/ и вставляет ссылку на него в начало PAM-конфигурации sshd, sudo и su. С этого момента модуль отрабатывает на каждое событие аутентификации:
- Снимает учетные данные в открытом виде, пока они идут через auth-стек, еще до любой криптографической обработки.
- Выполняет заданные атакующим shell-команды по событиям аутентификации, в том числе по особым magic-password: такой пароль открывает root-шелл, и в lastlog с wtmp это не попадает.
- Выгружает снятые учетные данные по DNS или HTTPS на настроенный адрес C2.
- Переживает смену пароля: бэкдор сидит в стеке PAM, а не в учетной записи.
- Переживает перезагрузку: модули PAM читаются с диска при каждом запуске процесса, демон регистрировать не нужно.
- В обычной работе не виден в ps и netstat: активируется только в момент аутентификации.

Постоянный процесс цепочке не нужен. Нечего убивать среди демонов, нечего снимать из cron, между событиями аутентификации нет подозрительного соединения, которое можно отследить. Все закрепление - один файл .so и правка конфигурации в одну строку. На беглый взгляд и то и другое выглядит как обычная установка PAM-модуля.

Статья про контроли обнаружения и предотвращения, которые ловят PamDOORa и атаки того же паттерна: подпись модулей через IMA/EVM, мониторинг целостности файлов для стека PAM, правила auditd и Falco на события записи в PAM, сверка PAM-модулей в рантайме с записями пакетного менеджера и ограничения AppArmor/SELinux на то, кто может писать в /lib/security/.

https://telegra.ph/Proverka-celostnosti-PAM-modulej-obnaruzhenie-behkdorov-vrode-PamDOORa-09-27

#ит_статьи #linux #pam #auditd #ima #hardening #security

Как снизить потребление оперативной памяти в Linux

Если поискать «как снизить потребление оперативной памяти в Linux», в основном вы найдёте списки параметров sysctl, которые предлагают просто скопировать: выставьте такое-то значение swappiness, сбросьте кеши, отключите вот это. Я ещё не видел, чтобы такой подход выдержал встречу с настоящим продакшен-сервером. Работает куда более скучный порядок: цикл «измерили - изменили - проверили», причём в правильном порядке. Сначала сокращаем рабочий набор приложений, затем изолируем сервисы, потом подключаем сжатие и покупаем память только тогда, когда цифры докажут: иначе никак.

Это заключительная часть серии. Она объединяет варианты настройки zram и zswap и лимиты systemd/cgroup в план, который можно пройти от начала до конца.

https://telegra.ph/Kak-snizit-potreblenie-operativnoj-pamyati-v-Linux-09-25

#ит_статьи #linux #ram #systemd #cgroups #zram #zswap

Ограничить RAM сервиса в Linux через systemd и cgroup v2

Кто уже какое-то время держит Linux-серверы, тот переживал какой-то вариант этого инцидента: один сервис (дырявое приложение, batch-джоба, запрос, ушедший вразнос) растет, пока весь хост не уходит в thrashing, и к тому моменту, когда просыпается OOM killer, он убивает то, что вам было дороже настоящего виновника. Работа с zram и zswap из предыдущей статьи защищает вас от пиков, но против этого не делает ничего.

Сейчас это важнее, чем раньше. При ценах на RAM 2026 года естественная реакция: уплотнять больше нагрузки на те хосты, которые у вас уже есть. И уплотнение здраво, только если отказ одного сервиса не может утянуть за собой остальные. Именно это дают вам cgroup v2 и systemd.

https://telegra.ph/Ogranichit-RAM-servisa-v-Linux-cherez-systemd-i-cgroup-v2-09-24

#ит_статьи #devops #linux #cgroups #systemd #ram

Zram, zswap и swap в Linux: практическое руководство по настройке

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

Скажу прямо одну вещь, потому что «просто включите zram» стало советом на автомате в каждой ветке форума про нехватку памяти: zram и zswap не создают свободную память. Они тратят циклы CPU на сжатие страниц, которые вы сейчас активно не используете. Когда данные хорошо сжимаются и у CPU есть запас, этот размен отличный. Когда этого нет, вы добавили слой сложности и ничего не получили. Так что цель здесь не включить всё подряд, а намеренно выбрать один механизм и доказать, что он помогает.

https://telegra.ph/Zram-zswap-i-swap-v-Linux-prakticheskoe-rukovodstvo-po-nastrojke-09-24

#ит_статьи #linux #zram #zswap #swap #ram

Настройка Secure Boot и TPM 2.0 в Proxmox для KVM-гостей

Proxmox умеет отдавать KVM-гостям UEFI Secure Boot и виртуальный TPM 2.0: к ВМ подключаются EFI-диск и диск состояния TPM. Для новых ВМ это короткая правка конфигурации. Для уже существующих гость должен быть установлен в режиме UEFI. На выходе получается цепочка загрузки, которая проверяет подписанные загрузчики и отдаёт измерения PCR, не меняя схему хранения и сеть.

https://telegra.ph/Nastrojka-Secure-Boot-i-TPM-20-v-Proxmox-dlya-KVM-gostej-09-23

#ит_статьи #devops #linux #proxmox #kvm #qemu #uefi #secureboot #tpm

Почему не стоит запускать 2-нодовый кластер Proxmox без третьего голоса

Proxmox умеет работать в двухнодовой конфигурации кластера. И для многих кто держит домашний кластер это отличный сетап, потому что третью ноду сначала еще нужно найти. Современные мини-ПК обладают большой вычислительной мощностью и памятью, чтобы крутить довольно много ВМ, LXC или Docker-контейнеров. Я полностью понимаю, почему многие начинают с пары хостов. Системы вроде MS-01, MS-03 и MS-A2 от Minisforum - отличные примеры мини-ПК, которые хорошо подходят для этой цели. Но есть ситуация, которая может возникнуть с двухнодовыми кластерами Proxmox, если они спроектированы неправильно.

https://telegra.ph/Pochemu-ne-stoit-zapuskat-2-nodovyj-klaster-Proxmox-bez-tretego-golosa-09-21

#ит_статьи #devops #linux #proxmox #homelab #corosync