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

VK Cloud, Yandex Cloud и «Флант». Долгое время каждый устраивал своё мероприятие и конкурировал за внимание одних и тех же людей. Потом собрали это в одну конференцию — Kuber Conf, проект их ассоциации АОТ. Первая прошла в 2025-м. Мне тут важно, кого зовут говорить. В программу обещают брать тех, кто проверял подходы на своих проектах и не стесняется сказать, где и что реально сработало, а что не очень. Днём обещают как раз это: инфраструктуру и модели, экономику платформ, безопасность, Kubernetes, сети и железо. В семь — афтепати. Подозреваю, основной доклад будет там, только без слайдов. Вся программа уже на сайте! Если вам это по работе близко — 22 октября, пространство Connect. Записи прошлого года уже есть. Я послушал и пожалел, что не мог посетить конфу очно. Очень много концентрированной полезной инфы от людей, которые явно хорошо знают своё дело.

Ошибки сетевого интерфейса в Linux: практический порядок диагностики через ethtool и ip -s Когда Linux-сервер сообщает о потерях пакетов, медленных передачах или связности с перебоями, первая ошибка часто в том, чтобы сразу лезть в логи приложения. Linux отдаёт несколько слоёв сетевой статистики: стандартные счётчики интерфейса, счётчики по протоколам и значения, специфичные для драйвера, которые доступны через ethtool. Аккуратный порядок действий подскажет вам, на каком уровне проблема: физика, драйвер, очереди или выше по стеку. https://telegra.ph/Oshibki-setevogo-interfejsa-v-Linux-prakticheskij-poryadok-diagnostiki-cherez-ethtool-i-ip--s-10-07 #ит_заметки #linux #ethtool #network #nic #troubleshooting

Собираетесь на SysAdmin 2026 9 октября? Тогда загляните к SafeMobile! С самого утра коллеги ждут на стенде №8: команда SafeMobile приглашает познакомиться и обсудить вопросы управления корпоративными устройствами. Подарки тоже будут 🎁 А в 16:30 в Общем треке технический директор SafeMobile Олег Ассур и руководитель направления ПАО Сбербанк Максим Микалюк выступят с докладом «Автономный MDM отбирает работу у meat proxy. Что делать?» Поговорят о том:

➡️ Что MDM умели делать самостоятельно ещё до ChatGPT; ➡️ Как ИИ уже используют мировые MDM-решения; ➡️ Сколько самостоятельности можно доверить системе; ➡️ Как контролировать риски, когда она действует сама; ➡️ Как при этом меняется роль администратора.

📍 Москва, Раменский бульвар, д. 1, кластер «Ломоносов» Хотите разобраться в теме ещё до доклада? В канале SafeMobile — всё об управлении и защите корпоративных устройств, практических кейсах и возможностях MDM.

WinPodX — Windows, встроенная прямо в Linux Разве не было бы здорово, если бы двойной щелчок по файлу .docx в файловом менеджере Linux просто открывал Word? Без полноэкранного рабочего стола Windows и без сеанса удалённого рабочего стола — просто обычное окно Word со своей иконкой на панели задач, которое можно закрепить и между которым можно переключаться через Alt+Tab, как между любыми другими приложениями. Именно это и делает WinPodX: он запускает Windows-контейнер в фоне под KVM и выводит отдельные приложения с помощью FreeRDP RemoteApp. Благодаря этому ссылки mailto: открываются в Outlook, а схемы slack: или vnc: — в тех приложениях, которые зарегистрированы для их обработки. https://telegra.ph/WinPodX--Windows-vstroennaya-pryamo-v-Linux-10-05 #ит_заметки #linux #windows #kvm #freerdp #remoteapp

Наш душевный спагетти-код, их бездушный нейрослоп😏 #ит_юмор #ai

Кластер высокой доступности с Pacemaker и Corosync на RHEL-based дистрибутивах Непрерывная доступность критичных приложений для бизнеса в цифровой среде обязательна. Кластер высокой доступности (HA) дает механизмы резервирования и failover, без которых простой не сократить: сервисы остаются онлайн даже при отказе серверов. В экосистеме RHEL-based дистрибутивов Pacemaker и Corosync - два мощных инструмента для эффективной сборки кластеров высокой доступности и управления ими. Речь о настройке двух- или многоузлового HA-кластера на Pacemaker и Corosync на RHEL-based дистрибутивах. В статье - как кластеризация помогает управлять критичными сервисами вроде баз данных и файловых систем и обеспечивает бесшовный failover, чтобы свести перебои в работе сервиса к минимуму. #ит_статьи #devops #linux #pacemaker #corosync #failover #high_availability

Как пакет проходит через ядро 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

Читать можно. Писать — нет NVIDIA выпустила Open Agent Safety Platform. Вместе с ней — OpenShell 0.1.0. Это не новый агент. OpenShell не заменяет Codex, Claude Code, Hermes и прочие, а оборачивает их запуск. Агент сидит в песочнице: на уровне ОС ограничиваются файлы и процессы. Рядом Supervisor проверяет исходящий трафик — HTTP, GraphQL и MCP. Политики пишут на YAML. Дальше они компилируются в правила OPA Rego и проверяются на каждый исходящий запрос. К одному и тому же API можно разрешить чтение и запретить запись. Обычная библиотечная история: книгу дают, карандаш — нет. Секреты агенту не отдают: они остаются вне его workload. При этом сервис, куда он стучится, свои права всё равно проверяет сам — OpenShell добавляет ещё один слой контроля, а не заменяет авторизацию сервиса. По умолчанию сети может не быть вообще — тогда curl падает ещё на уровне ядра. Разрешить только чтение GitHub API можно одной командой, причём песочницу перезапускать не надо. Каждое решение политики остаётся в журнале OCSF. На железе эту схему дополняет NVIDIA Sentry. Она работает на BlueField-4, не на третьем поколении — у BlueField-3 заметно меньше вычислительной мощности. В системах Vera Rubin POD эти DPU стоят на единственном пути к модели. Через NVIDIA DOCA Sentry связывает разговоры агента, решения политик и обращения к инструментам в контекстные записи активности. На испытаниях агенты до двух часов уговаривали ИИ-ревьюеров дать им права на изменение защищённого репозитория. Уговаривать им не тяжело, не устают. OpenShell в это время показывал ревьюерам, что запрашиваемые права на самом деле позволяют, даже когда агент пытался ими манипулировать. Записей в защищённые репозитории не произошло. Версия пока 0.1.0. К проекту уже присоединились сто организаций из экосистемы NVIDIA. #ит_заметки #openshell #nvidia #ai

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

Бесплатный урок: права доступа к файлам в Linux 🐧 Разбор того, как устроены права в Linux, как их читать через ls -l, как менять с помощью chmod и chown, где чаще всего ошибаются новички и как не наломать дров с правами на реальном сервере. Урок из курса «Администрирование ОС Linux» - та же подача и та же глубина, что и на всей программе. Ведёт Кирилл Казарин - 15 лет в администрировании, 8 лет в DevOps. 👉 Забрать урок

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

Планы на 3 октября — прийти на RWB Infra x Security Meetup Мы направим прожекторы на инфраструктуру и информационную безопасность — туда, где за привычными решениями скрываются сложные инженерные задачи, компромиссы и неочевидные риски. Будем разбирать реальные кейсы, искать узкие места, обсуждать и показывать решения, которые помогают инфраструктуре и безопасности выдерживать рост. Когда: суббота, 3 октября, старт в 13:00 Где: Москва + онлайн В программе 8 докладов, разделенных по двум тематическим трекам Трек Infra: • Тюнинг Gitlab CE как реакция на быстрый рост нагрузки • Путь баланса и компромиссов в DCIM • Единая инфраструктура доверия: PKI на базе Vault • Kubernetes vs Bare Metal: что может пойти не так Трек Security: • DevSecOps: от сканирования в пайплайне к платформе — и обратно • Почти эффективный VM: как мы боролись с хаосом в инфраструктуре и сократили время обработки уязвимостей • Как защищать данные, когда единого периметра больше нет • От заявки до доступа за 90 секунд: как шесть инженеров управляет доступом в тысяче систем Регистрация уже открыта — не откладывайте заявку и приглашайте коллег (количество мест на площадке ограничено)! Подробнее о программе — на сайте

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

Что крупные заказчики проверяют на пилоте NGFW Чем крупнее сеть, тем выше требования к NGFW. Выдержит ли он пиковую нагрузку при активных IPS и инспекции зашифрованного трафика? Сохранятся ли соединения при отказе узла? Как отработает переключение между каналами при росте задержек и потере пакетов? Обнаружит ли обращения к ИИ-сервисам в обход ИБ? За год Novum прошёл проверку в реальной эксплуатации у крупных заказчиков. 📅 1 октября, 11:00 (мск) «Ideco NGFW Novum год спустя: новые возможности для крупных инфраструктур» Расскажем: ▪️ что нового в масштабировании, отказоустойчивости и управлении; ▪️ что проверяли заказчики на пилотах и с какими результатами; ▪️ SD-WAN и QoS на нагруженных каналах; ▪️ Shadow AI Discovery: 84 AI-сервиса, распознавание без расшифровки TLS; ▪️ независимые оценки и планы развития. Онлайн с записью, участие бесплатное. Зарегистрироваться ➡️

Seccomp, Seccomp и syscall'ы: BSidesSF и seccomp в Kubernetes Раньше было сложно объяснить людям все причины, по которым им нужно защищать свой кластер. Мы придумывали натянутые примеры разных путей эксплуатации внутри Kubernetes, но до недавнего времени самой вероятной атакой были скучные старые криптомайнеры. Всё изменилось. Атакующие эволюционировали. Можете посмотреть на LinksPro как на пример руткита на eBPF, рассчитанного на компрометацию даже контейнерных окружений. Или ещё актуальнее прямо сейчас, TeamPCP - угроза момента, которая прямо сейчас активно целится в кластеры Kubernetes, разворачивает привилегированные DaemonSet'ы, чтобы перемещаться по окружениям и вытягивать секреты. Но можно и проще: у нас куча агентных workload'ов и окружений для разработки AI, которые хочется запесочить. Конечно, Kubernetes всплывёт как решение. И конечно, им нужны гарантии изоляции покрепче, чем просто контейнер. Есть сетапы на microVM вроде firecracker или эмулированные ядра вроде gVisor. Это отличные решения, и они работают. Сходите посмотрите. Сегодня поговорим про Seccomp. https://telegra.ph/Seccomp-Seccomp-i-syscally-BSidesSF-i-seccomp-v-Kubernetes-09-28 #ит_статьи #devops #kubernetes #linux #seccomp #syscall #containers

Вот это подгон: лидеры Альфа-Банка и других крупных компаний прямо сейчас нанимают в Сетке, соцсети для нетворкинга от hh ru. Пишите нанимающим напрямую, так вас точно заметят. И, кто знает, может среди этих вакансий есть команда вашей мечты: → CTO Альфа-Банка Кирилл Сафаров ищет руководителя портфеля цифровых продуктов на MLM-проект «Свой в Альфе»; → IT-директор Сергей Чернуха из «Филип Моррис Интернэшнл» в России в поиске сразу двух управляющих: IT-решениями для бизнеса и IT-инфраструктурой; → Техлид команды тестирования в Альфа-Банкее Егор Шохин ищет автотестировщика на C# уровня мидл+; → CTO МТС Банка Кирилл Золотарев ищет технического лидера в команду платежей; → Коммерческий директор Skillaz Андрей Синякин опубликовал вакансию директора по продукту

За столько лет работы в ИТ я повидал столько дерьма, что этот сертификат мне должны выдать без экзамена #ит_юмор #microsoft #certificate #expert

Проверка целостности 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