Источники ПО: официальные репозитории и суммы

Список установленных пакетов отвечает на вопрос «что уже лежит на сервере». Этот материал — про предыдущий шаг: откуда пакет вообще имеет право появиться. Если администратор ставит программу скриптом с произвольной страницы, реестр и сканер потом честно опишут вредоносный файл. Зафиксируйте разрешённые источники, проверяйте контрольные суммы установщиков и не используйте конвейер «скачать страницу — выполнить как root».

Статья опирается на логику направления «Управление ИТ-активами» из методики зрелости Группы Сбер (источник); это методика для крупных компаний, мы используем её как ориентир и пересказываем своими словами. Что уже стоит на хосте: учёт ПО и версий. Команды ниже только читают конфигурацию или считают хэш файла; применяйте на тестовой машине, если меняете списки репозиториев.

Что считать согласованным источником

Допустимо	Недопустимо без отдельного решения
Официальные репозитории дистрибутива (Debian, Ubuntu, Rocky, Astra, РЕД ОС) с проверкой подписи	Произвольное зеркало без HTTPS и без подписи
Репозиторий производителя ПО с ключом в `/usr/share/keyrings/` и параметром `signed-by`	`curl … \| sudo bash`, установщик с форума, ссылка из мессенджера
ISO и установщик с сайта вендора после сверки SHA-256 с той же страницы	Файл с того же имени, скачанный с файлообменника
Закреплённые зависимости с хэшами в конвейере	Пакет Python или образ контейнера «последняя версия» без фиксации

Правая колонка не «навсегда нельзя», а «сначала решение ответственного за ИБ и запись в перечень». Сам перечень: разрешённое и запрещённое ПО. Для зависимостей Python хэши уже разобраны отдельно: pip-audit и require-hashes.

Шаг 1. Посмотрите текущие источники

На Debian 12 и Ubuntu список репозиториев лежит в /etc/apt/sources.list и в /etc/apt/sources.list.d/. Команда не меняет систему:

apt-cache policy
ls -l /etc/apt/sources.list /etc/apt/sources.list.d

В выводе apt-cache policy для каждого пакета видны кандидат и откуда он берётся. Строки с неизвестным вам узлом или с http:// без подписи — повод разобрать источник, а не ставить обновление «пока ставится».

Не добавляйте ключ устаревшей командой apt-key add из потока curl: ключ попадает в общее связкохранилище и подписывает любые репозитории. Для стороннего репозитория вендора положите его ключ в /usr/share/keyrings/ИМЯ.gpg и укажите signed-by только для этой строки. Пример (узел замените на адрес из документации производителя, не на случайный):

deb [signed-by=/usr/share/keyrings/VENDOR.gpg] https://example.com/repo stable main

Риск ошибки в файле источника: apt update начнёт доверять чужому архиву. Держите копию прежнего sources.list и проверяйте синтаксис на тестовой машине до переноса на сервер.

Шаг 2. Проверьте установщик по контрольной сумме

Для образа Debian сверяйте хэш с подписанным файлом сумм на официальной странице проверки образов, а не с текстом в блоге: debian.org/CD/verify. Скачайте образ и файл сумм с того же официального каталога, затем:

sha256sum ИМЯ.iso

На экране — одна строка: хэш и имя файла. Она должна побайтно совпасть со строкой в SHA256SUMS для этого имени. Если не совпала — не монтируйте образ и не записывайте его на носитель: либо битая загрузка, либо подмена.

На Windows ту же проверку делает встроенная команда (документация Microsoft Learn). В каталоге с файлом:

Get-FileHash -Algorithm SHA256 .\\ИМЯ.exe

Сравните поле Hash с суммой на сайте производителя. Не берите сумму из комментария к файлу на стороннем каталоге.

Шаг 3. Запретите установку скриптом из интернета

Запишите в инструкцию администраторам: установка «скопировать команду со страницы проекта» без разбора содержимого запрещена. Если вендор отдаёт только скрипт, скачайте его, прочитайте, положите в свой репозиторий и запускайте уже свою копию. Исключение оформляется как в перечне ПО, с датой пересмотра.

Образы контейнеров проверяйте отдельно: Trivy по образу и секретам, а не «latest с Docker Hub без тега».

Диагностика

Симптом	Причина и что делать
`apt update` ругается на подпись	Ключ не тот или истёк. Не отключайте проверку подписи. Возьмите ключ с документации вендора в `keyrings`
Хэш ISO не совпал	Повреждение или подмена. Скачайте заново с официального каталога, не «докачивайте» с другого зеркала
В `policy` пакет приходит с неизвестного узла	Лишний файл в `sources.list.d`. Снимите его, пока не будет решения ИБ
Администраторы ставят ПО через личный браузер на сервер	Нет согласованного источника. Закройте прямой выход в интернет с серверов и выдайте внутреннее зеркало или репозиторий

Где это в модели зрелости

Материал относится к направлению «Управление ИТ-активами» (хаб: управление ИТ-активами, карта: карта зрелости). Реестр серверов закрывает вопрос «какие узлы есть». Согласованные источники закрывают вопрос «кто имеет право класть код на эти узлы». Без этого учёта пакетов недостаточно: вредоносный установщик тоже попадёт в CSV.

Как проверить

По apt-cache policy на тестовом сервере видны только известные вам репозитории.
Сторонние репозитории, если есть, указаны с signed-by и ключом в /usr/share/keyrings/.
Для последнего скачанного ISO или установщика сохранена строка SHA-256 и ссылка на страницу вендора, с которой её взяли.
В инструкции администраторов есть прямой запрет на curl | bash и установку с файлообменников.
Исключения из правила заведены в перечне ПО с датой пересмотра, а не живут в чате.

Источники

Debian, проверка подлинности образов: debian.org/CD/verify.
Microsoft Learn, Get-FileHash: learn.microsoft.com.
CIS Controls v8.1, контроль 2 (учёт программного обеспечения). Это не закон РФ: cisecurity.org.
Методика оценки уровня зрелости кибербезопасности компании, Группа Сбер: sberbank.ru.