Вредонос в AUR: как не угробить Arch Linux одной командой

Любите Arch Linux, но новости про вредоносы в AUR заставляют нервничать? Это нормально. В июле 2025 года произошло сразу два примечательных инцидента. 16 июля в AUR-пакетах librewolf-fix-bin, firefox-patch-bin и zen-browser-patched-bin обнаружили удалённый троян CHAOS RAT . А 31 июля в AUR появился переупакованный google-chrome-stable, чей build-скрипт содержал однострочник Python, скачивавший и исполнявший удалённый скрипт с ненадёжного сервера. В обоих случаях сообщество заметило проблему быстро, и в течение примерно 48 часов пакеты удалили. Но это лишний раз показало: открытая модель AUR требует дисциплины от каждого, кто ей пользуется.

Значит ли это, что AUR — всегда риск? Нет. AUR остаётся мощным инструментом, если пользоваться им осознанно: проверять, что именно вы ставите, понимать, как устроена сборка, минимизировать поверхность атаки и иметь быстрый план реагирования.

Почему AUR уязвим — и зачем он вообще нужен

AUR — это большая библиотека пользовательских рецептов (PKGBUILD) под Arch Linux. Любой может предложить новый пакет, а другой — собрать его у себя локально. Сила AUR — скорость и широта: свежие версии, редкие утилиты, смелые форки. Слабость — та же: нет формальной премодерации кода, публикации появляются почти мгновенно, а «осиротевший» пакет может подхватить новый сопровождающий и незаметно добавить лишние действия. Злоумышленники либо выпускают «двойника», либо захватывают заброшенный рецепт и включают лишний код.

Важно помнить: вредонос не прилетит сам. Он сработает только если вы установите пакет или обновите уже установленный. Значит, задача — распознать подозрительное до установки и не нажимать «Да» на автопилоте.

Базовая стратегия: используем AUR осознанно

Если вы новичок или не хотите углубляться, отличная новость: подавляющее большинство нужных приложений есть в официальных репозиториях или в Flatpak. AUR оставьте для редких случаев. Когда без AUR не обойтись, действуйте по плану ниже.

1) Регулярные резервные копии — прежде всего

Без бэкапа любой эксперимент — риск. Делайте инкрементальные копии с rsync (или restic, borg) и храните на отдельном носителе, который не висит постоянно в системе. Можно использовать внешний SSD (например, Crucial X10) — главное, чтобы он был физически отдельным и не всегда подключённым.

2) Будьте в курсе: уведомления и сообщества

Настройте Google Alerts на ключевые слова Arch и AUR — получите ежедневные дайджесты. Подпишитесь на сабреддиты r/archlinux и r/linux: там часто обсуждают уязвимости, снятые пакеты и кампании со вредоносами — иногда раньше, чем в крупных СМИ.

3) Octopi или терминал — выбирайте, где удобнее проверять

Мне удобно первично смотреть пакеты через Octopi: ввожу имя — вижу все совпадения и из какого репозитория каждый вариант. На вкладке «Информация» — метаданные, сопровождающий, ссылка на проект. Я больше доверяю пакетам, где у сопровождающего корпоративный домен (например, связанный с дистрибутивом или archlinux.org). Если указана общая почта вроде xyz@gmail.com или контакт не указан вовсе — открываю страницу пакета в AUR и разбираюсь глубже, прежде чем нажимать «Установить». Любите терминал — пожалуйста: логика проверки та же, просто вручную.

Как «просветить» пакет из AUR до установки

Перед установкой скачайте рецепт и посмотрите, что он делает. Цель — открыть PKGBUILD и убедиться, что там нет лишней сети, однострочников, которые подтягивают и исполняют удалённый код, и других «сюрпризов».

Шаг 0. Скачиваем рецепт, не устанавливая

git clone https://aur.archlinux.org/имя-пакета.git
 cd имя-пакета
 

Если пользуетесь помощником, возьмите только файлы рецепта: yay -G имя-пакета или аналог в paru.

Шаг 1. Смотрим на сопровождающего, комментарии и историю

Проверьте, кто поддерживает пакет, давно ли в экосистеме, не «подхвачен» ли недавно осиротевший рецепт. Нравятся пакеты, где сопровождающий в сообществе не первый день и отвечает в комментариях. Пустота под подозрительным рецептом — плохой знак. По журналу изменений оцените, когда пакет попал в AUR и кто его вёл. Лично я чувствую себя спокойнее, когда текущий сопровождающий ведёт пакет хотя бы месяц, лучше — полгода.

Шаг 2. Быстрый самоаудит PKGBUILD «по чек-листу»

• Блок source и суммы: источники — официальные домены, есть корректные sha256sums, ничего не докачивается «на лету» в prepare()/package().
• Никаких «curl | bash» и «однострочников», тянущих и запускающих удалённый скрипт.
• Без sudo — рецепт сборки не должен требовать привилегий суперпользователя.
• Сетевые операции при сборке — табу: всё должно скачиваться заранее через source и проверяться хешами.

Шаг 3. Не программист? Поможет ИИ — но с оговорками

Когда сомневаюсь, копирую PKGBUILD целиком и отправляю в Google AI Studio с просьбой проверить подозрительные места . Там доступен Gemini 2.5 Pro, который неплохо читает код и указывает на рискованные действия. Но это лишь дополнительная проверка: модели могут ошибаться. Если ИИ что-то подсвечивает, лучше спросить у опытного человека.

Шаг 4. Собираем безопасно

Лучше всего — в чистом chroot с набором devtools (например, extra-x86_64-build): рецепт исполняется в изоляции, без доступа к вашему домашнему окружению. Если собираете «вживую», используйте хотя бы makepkg -Crs, чтобы чистить зависимости и мусор после сборки.

Помощники AUR (yay/paru): удобство без автопилота

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

Минимизируем поверхность атаки: уборка и инвентаризация

Удаляем осиротевшие зависимости

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

pacman -Qdt
 

Удалить конкретный пакет и его хвосты:

sudo pacman -Rns имя-пакета
 

Убрать все осиротевшие зависимости разом:

sudo pacman -Rns $(pacman -Qdtq)
 

Проверяем «иностранцев» и ищем подозрительное

Вывести установленные пакеты не из официальных репозиториев (AUR/локальные):

pacman -Qm
 

Поиск по названиям и описаниям:

pacman -Qs ключевое-слово
 

Чистим следы сборки

После установки удаляйте папки с исходниками и временные файлы. Если используете помощник, включите очистку кеша. Чем меньше «строительного мусора», тем меньше сюрпризов при будущих обновлениях.

Если случилось худшее: план действий при компрометации

Допустим, вы прочитали, что конкретный пакет из AUR оказался вредоносным. Проверяем, установлен ли он у вас:

pacman -Qs имя-пакета
 

Список всех установленных пакетов из AUR:

pacman -Qm
 

1. Отключите интернет (Wi-Fi/кабель), чтобы пресечь догрузки и утечки.
2. Удалите пакет с конфигами и зависимостями: sudo pacman -Rns имя-пакета.
3. Перезагрузитесь и стартуйте с живой флешки Linux. Просканируйте установленную систему антивирусом (например, ClamAV ) и утилитами для поиска руткитов (chkrootkit или rkhunter).
4. Оцените масштаб. Если пакет мог дать удалённый доступ или исполнял произвольный код, разумно считать систему потенциально скомпрометированной целиком. Надёжнее всего — чистая переустановка из проверенного образа и восстановление данных из чистой резервной копии.
5. Смените секреты: пароли (в первую очередь почта и банк), SSH-ключи, токены в сервисах разработчика. Отзывайте старые, генерируйте новые.

Частые вопросы

Правда ли, что «AUR небезопасен, точка»? Нет. Опасна слепая установка. Если читаете PKGBUILD, проверяете сопровождающих и собираете в изоляции, риск резко падает.

Как понять, что в PKGBUILD «всё плохо», если я не программист? Проверьте источники и суммы, отсутствие сетевых докачек в prepare()/package(), отсутствие «curl | bash» и sudo. При сомнениях — спросите у сообщества и прогоните файл через Google AI Studio (Gemini 2.5 Pro) как дополнительный фильтр.

Антивирус на Linux поможет? Это последняя линия, не замена гигиене. Полезно для поиска «хвостов» после удаления вредоноса, но ключ — не устанавливать сомнительное и собирать в чистом окружении.

Насколько быстро сообщество реагирует? В июле 2025 вредоносные публикации убрали в течение приблизительно двое суток. Но это не спасёт тех, кто успел установить пакет «в окно». Значит, профилактика — на вашей стороне.

Короткий боевой чек-лист

• По умолчанию ставьте из официальных репозиториев или Flatpak. AUR — только осознанно.
• Перед установкой из AUR: скачать рецепт, проверить PKGBUILD, оценить сопровождающего/комментарии/историю.
• Собирайте в чистом chroot (devtools) или хотя бы makepkg -Crs.
• Регулярно чистите orphan-пакеты: pacman -Qdt → sudo pacman -Rns.
• Держите резервные копии на отдельном носителе.
• Следите за Google Alerts и сабреддитами r/archlinux, r/linux.
• При подозрении на компрометацию: офлайн → удалить пакет → скан из live-среды → при необходимости — чистая переустановка и смена секретов.

Итог

Открытость AUR — не баг, а особенность. Она даёт скорость и широту выбора, но требует внимательности. Если научиться читать PKGBUILD, собирать в изоляции, убирать за собой и держать ухо востро, AUR останется тем, чем и задуман: способом получать нужное ПО тогда, когда оно действительно нужно — без лишних рисков.