Linux: Настрой и забудь. Автоматические обновления безопасности с Unattended-Upgrades

Обновлять пакеты вручную — хорошая практика, но на десятках или сотнях серверов она нереализуема. Пропущенное обновление безопасности может стать причиной взлома.

Архитектурно правильное решение — автоматизировать установку только критически важных обновлений безопасности, чтобы минимизировать риски простоя и обеспечить базовую защиту. В Ubuntu/Debian для этого есть unattended-upgrades.

Пошаговая настройка:

Установка (если его ещё нет):

Bash

sudo apt update
sudo apt install unattended-upgrades

Основная конфигурация:
Откройте файл /etc/apt/apt.conf.d/50unattended-upgrades. Найдите и раскомментируйте (уберите //) строку, отвечающую за security-апдейты:

// Раскомментировать эту строку:
"${distro_id}:${distro_codename}-security";

Это разрешает установку обновлений только из репозитория безопасности.
В этом же файле можно настроить отправку отчётов на email или автоматическую перезагрузку, если она требуется.

Включение автоматического запуска:
Откройте файл /etc/apt/apt.conf.d/20auto-upgrades и убедитесь, что его содержимое выглядит так:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Первая строка включает ежедневное выполнение apt update. Вторая — ежедневный запуск unattended-upgrade.

Проверка и отладка:
Вы можете запустить процесс в "сухом" режиме, чтобы посмотреть, что именно будет обновлено:

Bash

sudo unattended-upgrades --dry-run --debug

Все логи работы хранятся в /var/log/unattended-upgrades/.

Взгляд архитектора:
Это не просто скрипт в кроне. Это компонент зрелой стратегии управления уязвимостями. Он обеспечивает постоянный базовый уровень безопасности для всего парка машин, освобождая время инженера для более сложных задач. Риск "сломать всё" минимален, так как обновления приложений и ядра (которые могут повлиять на совместимость) остаются для установки вручную.

#linux #security #automation #ubuntu #debian #гайд

🐧 Linux: Debian 14 «Forky» вводит обязательные воспроизводимые сборки — и это меняет supply chain security

Коллеги, 10 мая Debian Release Team объявила о решении которого ждали годами. Debian теперь блокирует пакеты, не прошедшие проверку воспроизводимой сборки, от попадания в testing. Это работает с 9 мая, во время текущего цикла разработки Forky. Правило распространяется и на уже существующие пакеты — если обновление нарушает воспроизводимость, миграция блокируется.

Что такое reproducible builds на практике:

Когда пакет собирается воспроизводимо, компиляция одного и того же исходного кода в одном и том же окружении каждый раз даёт идентичный бинарный файл. Это позволяет любому проверить, что дистрибутируемые бинари соответствуют опубликованному исходному коду. Звучит как само собой разумеющееся — но на практике это не так. Метки времени в сборке, случайные идентификаторы, порядок файлов — всё это делает бинари разными при каждой сборке.

Почему это важно именно сейчас:
Независимо верифицируемый путь от исходного кода к бинарному файлу становится всё более критичным с точки зрения безопасности цепочки поставок. XZ Utils backdoor, атаки на npm-пакеты, скомпрометированные CI/CD пайплайны — всё это атаки на supply chain. Reproducible builds делают их детектируемыми.

# Как проверить воспроизводимость пакета в Debian прямо сейчас:
# Смотрим статус на reproduce.debian.net
curl -s "https://reproduce.debian.net/api/v0/pkgset/by_name/unstable/openssh" \
    | python3 -m json.tool | grep -E "status|suite"

# Для своей системы — проверяем установленные пакеты через debsums:
apt install debsums
debsums -c  # проверяем контрольные суммы файлов

# Для разработчиков пакетов — проверяем воспроизводимость через reprotest:
apt install reprotest
reprotest -- dpkg-buildpackage -b .
# Собирает пакет дважды в разных условиях и сравнивает результат

# Смотрим общий дашборд воспроизводимости Debian:
# https://reproduce.debian.net/
# На момент анонса: >98% пакетов уже воспроизводимы на всех архитектурах

Debian 14 «Forky» также станет первым релизом с нативным rollback, undo и историей операций в APT package manager. Выход ожидается в июне-августе 2027 года.

Итог: reproducible builds — это не академия. Это инфраструктурный фундамент доверия к пакетам. Debian сделал это обязательным. Остальным дистрибутивам теперь неловко этого не делать.

#linux #debian #security #supplychain #sysadmin #admin_future

🐧 Linux: Rust теперь в APT — и это важнее чем кажется

Коллеги, на этой неделе случилось кое-что, о чём мало кто написал — но что касается каждого администратора Debian/Ubuntu-флота напрямую.

Два события мая 2026 окончательно переместили Rust из категории «языка будущего» в load-bearing инфраструктуру. Первое: Linux 7.0 убрал пометку experimental с Rust — теперь это официальный язык ядра наравне с C. Второе: APT maintainer Julian Klode объявил что Debian's package manager начинает требовать жёсткую зависимость от Rust начиная с мая 2026.

Что это значит практически для администратора:

APT — это package manager для Debian и каждого производного дистрибутива: Ubuntu, Linux Mint, Pop!_OS, Kali Linux, Raspberry Pi OS. Rust-компилятор, стандартная библиотека и части Sequoia PGP теперь встроены в core APT — для парсинга .deb, .ar и .tar файлов, а также HTTP signature verification.

Зачем Rust именно здесь? APT обрабатывает недоверенные данные (пакеты из интернета) на уровне root. Memory corruption в парсере пакетов — это immediate root compromise. Rust устраняет целые классы уязвимостей вроде use-after-free, которые типичны для C-кода. Это интеграция снижает реальную поверхность атаки в местах где это наиболее критично.

# Проверяем Rust в APT на Ubuntu 26.04:
apt-cache show apt | grep -i rust
dpkg -l | grep -i "rust\|rustc"

# Для администраторов air-gapped сред:
# APT теперь требует rustc при сборке из исходников
# Проверяем что offline-репозиторий включает rust-пакеты:
apt-get install --dry-run apt 2>&1 | grep -i rust

# Для Debian 13 Forky (выход 2027):
# Rust будет требоваться для сборки ядра модулей через DKMS
# Уже сейчас можно подготовить offline-кэш:
apt-get download rustc cargo libstd-rust-dev

# Смотрим версию Rust в системе:
rustc --version 2>/dev/null || echo "Rust not installed"
# На Ubuntu 26.04 должно быть 1.80+ из репозитория

Для администраторов air-gapped и закрытых сред — это практическое действие сейчас: убедись что твои offline-репозитории содержат rust-пакеты. После обновления APT на системах без сети это может сломать apt upgrade если Rust недоступен.

Итог: Rust перешёл из «интересно, но не моя проблема» в «часть базовой инфраструктуры моего дистрибутива». Пятница — хороший момент проверить offline-репы.

#linux #rust #debian #ubuntu #apt #security #sysadmin #admin_future

🔐 APT учится SHA3: Ubuntu готовится к дню, когда SHA-2 падёт. Зачем это нужно уже сейчас

Коллеги, понедельник. Сегодня пост не про очередную горящую CVE на периметре, а про эталонную инженерную предусмотрительность и архитектурную дальновидность.

📌 ФАКТЫ
Инициатива: инженеры Canonical (в частности, Gianpiero Carpinelli) внесли в апстрим пакетного менеджера APT поддержку семейства хешей SHA3-256 и SHA3-384 для проверки целостности индексных файлов (Release, Packages, Sources).

Дефолт не меняется: SHA-256/SHA-512 остаются базовым стандартом. Поддержка SHA3 внедряется как спящий резервный механизм.

Математика жизненного цикла: современные Enterprise-релизы (такие как Ubuntu 24.04 LTS в рамках расширенной поддержки Ubuntu Pro) живут 10–12 лет — то есть вплоть до 2036 года. Если на этом горизонте математический аппарат SHA-2 даст критическую трещину, миллионы установленных хостов должны уметь валидировать пакеты по альтернативному алгоритму без аврального обновления самого APT.

Текущий статус криптографии: семейство SHA-2 (SHA-256/512) не скомпрометировано, практических атак нет. При аппруве патча в апстриме Debian/APT функционал планируют бэкпортировать в LTS-ветку 24.04.

🛠 АУДИТ РЕПОЗИТОРИЕВ И КЛЮЧЕЙ В СИСТЕМЕ
Пока Canonical закладывает фундамент на 10 лет вперед, полезно проверить, нет ли в вашей системе хвостов из прошлого века:

Bash

# 1. Какие типы хешей фактически задействованы в ваших текущих InRelease
grep -hoE '^(MD5Sum|SHA1|SHA256|SHA512|SHA3-[0-9]+):' \
  /var/lib/apt/lists/*InRelease 2>/dev/null | sort | uniq -c

# 2. Поиск устаревших GPG-ключей репозиториев (RSA 1024, DSA и legacy-форматы)
for k in /etc/apt/trusted.gpg.d/* /usr/share/keyrings/*; do
  [ -f "$k" ] || continue
  echo "== Файл: $k"
  gpg --show-keys "$k" 2>/dev/null | grep -E '^pub'
done

💡 В ЧЁМ СУТЬ

В криптографии это называется crypto-agility (криптографическая гибкость) — способность инфраструктуры переключиться на новые криптопримитивы без необходимости менять сам софт и переустанавливать ОС на клиентах.

Обновить центральное зеркало репозитория можно за полчаса. А вот обновить пакетный менеджер на тысячах серверов, изолированных промышленных контроллерах или банкоматах, если проверка подписей внезапно сломается из-за компрометации алгоритма, — задача на месяцы аварийных работ.

🛡 НА ЧТО ОБРАТИТЬ ВНИМАНИЕ В СВОЕЙ СЕТИ
Пока ядро APT готовится к будущему, аналогичный вопрос стоит задать собственной инфраструктуре:

Собственные Nexus / Artifactory / Aptly: поддерживают ли ваши локальные пайплайны сборки пакетов современные алгоритмы хеширования и подписи?

SSH-инфраструктура: давно ли вы вычищали из authorized_keys и конфигов sshd старые ключи ssh-rsa (SHA-1) в пользу ed25519 и ecdsa?

Внутренний PKI / CA: какой алгоритм подписи выставлен на корневых и промежуточных сертификатах корпоративного центра сертификации?

#linux #debian #ubuntu #apt #crypto #security #sysadmin #admin_future

🧠 Skills: journalctl — 10 команд, которые заменяют grep по /var/log

Коллеги, навык недели. Начиная с Debian 12 rsyslog по умолчанию не ставится — классических текстовых логов на свежих инсталляциях может просто не быть. Всё уходит в бинарный журнал systemd-journald.

🛠 10 БАЗОВЫХ КОМАНД
Bash

# 1. Только ошибки (от err и выше) с момента текущего старта системы
journalctl -p err -b

# 2. Логи конкретного сервиса за последний час
journalctl -u nginx --since "1 hour ago"

# 3. Режим live-мониторинга (аналог tail -f) по конкретной службе
journalctl -u ssh -f

# 4. Список всех зафиксированных загрузок ОС (с их ID и временными метками)
journalctl --list-boots

# 5. Сообщения ядра (dmesg) за ПРЕДЫДУЩУЮ загрузку (ключевое при анализе падений)
journalctl -k -b -1

# 6. Фильтр по исполняемому файлу в чистом текстовом выводе
journalctl _COMM=sshd -o cat | grep -i 'failed'

# 7. Выборка событий в жестком временном окне
journalctl --since "2026-10-05 09:00" --until "2026-10-05 10:00"

# 8. Просмотр структуры записи со всеми служебными метаполями (для построения точных фильтров)
journalctl -o json-pretty -n 1

# 9. Проверка дискового пространства, занятого журналами прямо сейчас
journalctl --disk-usage

# 10. Ротация и очистка архивов старше 30 дней
journalctl --vacuum-time=30d

⚠️ ПРОВЕРЬТЕ ПЕРСИСТЕНТНОСТЬ (сохраняются ли логи после ребута)
Bash

# Проверка наличия каталога постоянного хранения
ls -d /var/log/journal 2>/dev/null && echo "Логи пишутся на диск" || echo "ВНИМАНИЕ: логи живут только в RAM до ребута!"

# Проверка конфигурации лимитов
grep -E '^(Storage|SystemMaxUse)' /etc/systemd/journald.conf

Если каталога /var/log/journal нет — журнал по дефолту сбрасывается в tmpfs (RAM). После аварийной перезагрузки расследовать причину сбоя будет физически невозможно:

Bash

# Включение постоянного хранения логов на диске
mkdir -p /var/log/journal && systemctl restart systemd-journald

💡 В ЧЁМ СУТЬ

Связка флагов

-b -1

и

-p err

закрывает 80% всех типовых инцидентов из серии «почему сервер упал ночью».

Персистентное хранилище на диске с жестко зафиксированным лимитом

SystemMaxUse

в

journald.conf

— обязательный базовый харденинг, который настраивается сразу после установки ОС.

#skills #linux #systemd #journalctl #debian #troubleshooting #sysadmin #admin_future

🖥 Proxmox: с сегодняшнего дня поддержка 24/7, а ветка 8.x уже без обновлений. Чек-лист перехода на 9

Коллеги, два события по Proxmox, которые стоит связать между собой.

📌 ФАКТЫ
С 19 октября Proxmox запускает круглосуточную enterprise-поддержку (Premium — сразу, Standard — в Q4 2026)

Proxmox VE 8 — конец поддержки в августе 2026. Debian 12 продолжает получать патчи через LTS до июня 2028, но pve-manager, qemu-server, pve-qemu-kvm, ядро Proxmox и Ceph обновляться перестали

Значит, свежие исправления вроде PwnEscape приходят в ядро PVE 9. Узлы на 8.x их не получат

🛠 ЧЕК-ЛИСТ 8 → 9
Bash

pveversion                     # сначала до последней 8.4 (pve-manager ≥ 8.4.1)
ceph --version                 # гиперконвергентный Ceph — сначала до Squid 19.2
df -h /                        # минимум 5 ГБ свободно, лучше 10+
pve8to9 --full                 # только проверяет и сообщает, ничего не меняет

Дальше узел за узлом: унести ВМ → репозитории на Trixie → apt dist-upgrade → перезагрузка → проверка → следующий узел. Репозитории переходят на формат deb822, помогает apt modernize-sources.

💡 В ЧЁМ СУТЬ

Поддержка 24/7 появилась, но платить за неё и сидеть на неподдерживаемой 8.x — плохая комбинация. Сначала обновление до 9 и бэкап в PBS, потом подписка.

#proxmox #virtualization #upgrade #debian #sysadmin #admin_future