Установка через curl | bash: как оценить риск и что смотреть

MAATRIX

Почти на каждой странице «Quick start» современного инструмента есть строчка вида curl https://example.com/install.sh | bash. Она удобна — одна команда, и всё стоит. Но если вдуматься, что именно происходит: вы скачиваете произвольный код с чужого сервера и тут же выполняете его от имени своего пользователя, не глядя. В конце августа 2026 года этот паттерн никуда не делся и вряд ли исчезнет — вопрос не в том, «плохой» он или «хороший», а в том, когда его можно запускать спокойно, а когда стоит потратить пять минут на проверку.

Почему curl | bash так распространён

Причина простая: это самый дешёвый способ дать пользователю одну команду, которая работает одинаково на Ubuntu, Debian, macOS и в WSL, не дожидаясь, пока пакет появится в репозитории дистрибутива. Через такой паттерн ставят себя менеджеры версий (rustup, nvm), пакетные менеджеры (Homebrew), рантаймы (Deno), удобные установщики CLI-инструментов и облачных SDK. Скрипт сам определяет ОС и архитектуру, скачивает нужный бинарник или настраивает окружение — то, что через apt install или .deb-пакет потребовало бы отдельной сборки под каждый дистрибутив.

Это не делает паттерн безопасным по умолчанию — просто объясняет, почему им пользуются даже крупные и уважаемые проекты, а не только сомнительные тулзы с форумов. Дальше важно не «доверять или нет одной команде», а понимать, что конкретно она может сделать и как это проверить до запуска.

Что технически происходит и где риск

Когда вы пишете curl URL | bash, происходит следующее: curl начинает стримить содержимое ответа сервера напрямую в stdin процесса bash, а bash исполняет команды по мере их поступления — построчно, без какой-либо паузы на просмотр. Три конкретных риска здесь:

• Права исполнения. Скрипт выполняется с правами вашего текущего пользователя. Если команда написана с sudo curl ... | sudo bash — с правами root, то есть без ограничений вообще: чтение любых файлов, запись в /etc, ~/.ssh/authorized_keys, системные cron-задания, правки firewall.
• Контент не гарантированно тот же, что вы видели. Сервер отдаёт ответ динамически и может формировать разный контент в зависимости от User-Agent, IP, географии, времени суток или количества обращений с одного адреса. curl по умолчанию шлёт свой User-Agent (curl/8.x), отличный от браузерного — теоретически сервер может отдать браузеру безобидную страницу с текстом скрипта, а по прямому запросу curl — другой файл. Это не значит, что так делает каждый сайт, но сама возможность существует, и полагаться на «я открыл ссылку в браузере и всё ок» — ошибка.
• Разрыв между просмотром и запуском (TOCTOU). Time-of-check to time-of-use: даже если вы открыли install.sh в браузере, прочитали его и он оказался чистым, а через минуту выполнили curl URL | bash — между этими двумя моментами содержимое по URL могло измениться. Ни HTTP, ни сам паттерн curl | bash не дают гарантии, что второй запрос вернёт то же самое, что первый, если только на сервере не настроена неизменяемость конкретной версии файла (например, версионированный URL или immutable release-ассет).

Отдельно: если сеть оборвётся на середине передачи, bash может успеть выполнить часть команд из недокачанного скрипта и упасть в неопределённом состоянии — это скорее операционная проблема, чем угроза безопасности, но тоже повод не гонять такие команды в проде без внимания.

Шаг 1 — разделяйте скачивание и запуск

Самое простое и самое эффективное правило: никогда не пайпите curl напрямую в bash. Разбейте на два шага:

curl -fsSL https://example.com/install.sh -o install.sh
less install.sh

Флаги -fsSL заставляют curl завершиться с ошибкой при HTTP-статусе 4xx/5xx (-f), не печатать прогресс-бар (-s), но показывать ошибки (-S) и следовать редиректам (-L) — без этого набора часто скачивается страница с текстом ошибки вместо самого скрипта, и она молча "выполняется" как валидный shell-код.

Дальше — реально прочитайте файл, а не просто откройте и закройте. На что смотреть в первую очередь:

grep -nE 'curl|wget|base64|eval|rm -rf|chmod 777|authorized_keys|/etc/(passwd|shadow|sudoers)' install.sh

Тревожные признаки:

• Обфускация: длинные base64-блоки, которые потом декодируются и передаются в eval или sh -c — если скрипт прячет часть логики, у вас нет способа понять, что он делает, не декодировав это вручную.
• Вложенные загрузки: curl ... | bash внутри самого скрипта, ведущий на другой, менее заметный домен — вы проверили верхний уровень, но не второй.
• Запись в SSH-конфиг — добавление ключей в authorized_keys, правка sshd_config. Легитимному установщику приложения это не нужно.
• Правки firewall или отключение защит — ufw disable, setenforce 0, массовые правила iptables -A INPUT -j ACCEPT.
• rm -rf с широкими путями и подстановкой переменных без кавычек — классический источник разрушительных багов, даже без злого умысла.

Если после чтения вопросов не осталось — запускайте локально сохранённую копию (bash install.sh), а не заново скачанный поток. Так вы гарантированно выполняете именно то, что прочитали.

Шаг 2 — проверяйте источник и целостность

Чтение кода снимает часть риска, но не весь — читаемый и «чистый на вид» скрипт всё равно может быть заменён на сервере через час. Здесь помогает репутация источника и криптографическая проверка:

• Домен. Официальный домен проекта — не сокращённая ссылка (bit.ly/...), не паста на стороннем хостинге, не зеркало. Ссылка из официальной документации на собственном домене проекта — совсем другой уровень доверия, чем та же команда, скопированная из комментария на форуме или из поста в соцсети.
• Чек-суммы и подписи. У зрелых проектов рядом со скриптом часто лежит файл с хешем или GPG-подписью:

curl -fsSL https://example.com/install.sh -o install.sh
curl -fsSL https://example.com/install.sh.sha256 -o install.sh.sha256
sha256sum -c install.sh.sha256

Если издатель подписывает релизы GPG-ключом, проверка выглядит так:

curl -fsSL https://example.com/install.sh.asc -o install.sh.asc
gpg --verify install.sh.asc install.sh

Это не защищает от компрометации самого сервера сборки, но снимает риск подмены на пути «сервер → вы» и подтверждает, что файл не тронули после подписания.

• Альтернативный способ установки. Если у проекта есть официальный APT/YUM-репозиторий, подписанный Docker-образ на Docker Hub/GHCR или бинарный релиз на GitHub с чек-суммами в releases — обычно у этого пути более выстроенная цепочка доверия (подпись пакета, воспроизводимость сборки, история версий), чем у динамически генерируемого shell-скрипта. Если выбор есть — он предпочтительнее.
• История и репутация репозитория. На GitHub — возраст репозитория, число контрибьюторов, открытые issues про сам install-скрипт, активность мейнтейнеров. Разовый скрипт от аккаунта без истории — повод насторожиться сильнее, чем инструмент с многолетней публичной историей.

Шаг 3 — запуск в изоляции для непроверенных источников

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

Одноразовый Docker-контейнер — самый быстрый вариант на своей машине:

docker run --rm -it --network bridge ubuntu:24.04 bash
# внутри контейнера
apt update && apt install -y curl
curl -fsSL https://example.com/install.sh -o install.sh
cat install.sh
bash install.sh

Контейнер изолирует файловую систему хоста, но не сеть по умолчанию — если хотите ещё и ограничить исходящие соединения, добавьте --network none и разрешайте доступ точечно, либо мониторьте трафик отдельно. Подробнее о том, как выстраивать такую изоляцию сервисов системно, — в статье про изоляцию через Docker для безопасности и в разборе лучших практик безопасности Docker.

Одноразовый VPS — вариант понадёжнее контейнера, если скрипт трогает системные настройки, ядро или сетевой стек так, что это не полностью видно изнутри контейнера. Поднимаете дешёвый сервер именно под тест, прогоняете install-скрипт, смотрите на результат и логи, при подозрении — уничтожаете инстанс и всё. Дешевле и быстрее, чем разбираться, что именно поломал непроверенный скрипт на боевой машине.

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

Сетевой мониторинг во время установки — параллельно откройте ss -tnp или iftop, чтобы увидеть, к каким адресам скрипт обращается. Легитимный установщик обычно ходит на 1-2 известных домена (сам проект, GitHub releases, CDN пакетов); россыпь незнакомых IP — повод остановиться.

Когда паттерн приемлем, а когда стоит насторожиться

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

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