Maran 1.0.0-beta.1 — первый устанавливаемый выпуск

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

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

Установка

curl -sSL https://get.maran.innovayse.com | sudo bash

Установщик скачивает артефакты, перечисленные в манифесте, подписанном релизным ключом проекта, и отказывается принимать всё, чья подпись или контрольная сумма не сходится. Манифест и названные в нём артефакты опубликованы на releases.maran.innovayse.com, а исходники на теге, из которого собран выпуск, — на GitHub.

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

Файлы и как проверить их самому

Всё, что скачивает установщик, опубликовано на releases.maran.innovayse.com и перечислено в манифесте, подписанном ключом релизов проекта.

Подписанный список — manifest.json, рядом с ним manifest.json.sig, а integrity-manifest.json записывает каждый файл внутри архивов, а не только сами архивы.

Если не хочется ничего направлять в root-шелл по трубе — та же установка без неё:

curl -O https://releases.maran.innovayse.com/installer/maran-installer.tar.gz
tar -xzf maran-installer.tar.gz
sudo bash installer/install.sh --channel beta

Публичный ключ, которым проверяет установщик, едет внутри этого пакета — installer/keys/release-signing.pub. Стоит сказать прямо: подпись, проверенная ключом, скачанным с того же хоста, доказывает лишь, что оба пришли из одного места. Чтобы доказать больше, сверьте этот ключ с копией в репозитории.

Что получает сервер

• Хостинг-аккаунты — настоящие пользователи Linux. Создание аккаунта заводит системного пользователя, домашний каталог и дисковую квоту тарифа на самом сервере; приостановка, возобновление и удаление тоже доходят до хоста. Сначала действует агент, потом появляется запись в базе — поэтому панель никогда не заявляет аккаунт, которого на сервере нет.
• Сайты — статические, PHP и обратный прокси — с алиасами доменов и корнем внутри домашнего каталога аккаунта. Агент рендерит конфигурацию, заставляет штатный валидатор сервера проверить результат и откатывает файл, если проверка или перезагрузка отказались, — поэтому плохой рендер не может уронить остальные сайты сервера.
• Несколько версий PHP одновременно, у каждого аккаунта свой пул на версию, работающий от его же пользователя Linux. Клиент может менять разрешённое подмножество настроек; имя вне списка отклоняется, а не отбрасывается молча.
• SSL по ACME с проверкой HTTP-01, загрузка собственных сертификатов и продление за тридцать дней до истечения. Ключи пишутся в хранилище, доступное только root и лежащее вне домашних каталогов, потому что PHP сайта работает от имени клиента.
• Базы данных с отдельным пользователем на каждую, лимитами тарифа и показом размера. Пароль генерируется, показывается один раз и не хранится — поэтому восстановление это сброс, а не извлечение.
• Передача файлов — SFTP штатным OpenSSH сервера, каждый вход заперт в jail, внутрь которого примонтирован настоящий домашний каталог аккаунта, с его же uid и без шелла. FTPS поставляется установленным, но выключенным: ничего не слушает, пока администратор его не включит.
• Резервные копии, журнал аудита только на дозапись по каждому входу и каждому изменению, живой просмотр логов, брандмауэр, мониторинг и консольная утилита maran.
• Вход в панель с Argon2id, короткоживущими токенами доступа, ротацией refresh-токенов, где повторно использованный токен отзывает всё семейство, TOTP с кодами восстановления и сессиями, которые можно отозвать по одной или все разом.

Чего он намеренно не делает

DNS, почта и веб-менеджер баз данных. Каждое отсутствует по решению, а не по недоделанности: менеджер баз данных запланирован отдельным развёртыванием со своим адресом и своей аутентификацией, а не наполовину сделанным здесь.

Прежде чем ставить туда, где это важно

Три ограничения стоит знать заранее — иначе оператор узнает о них трудным путём.

• Ни один сертификат не выпущен настоящим удостоверяющим центром. Весь путь при этом проходится целиком — регистрация, заказ, проверка HTTP-01, финализация, скачивание — против pebble, тестового сервера самого Let's Encrypt, причём серийный номер выданного сертификата совпадает с прочитанным из PEM. Это упражнение нашло настоящий дефект, которого не видел ни один тест: клиент не отправлял User-Agent, а pebble отклоняет такие запросы, Let's Encrypt же их терпит. Не проверен сам центр: ни его лимиты, ни проверка из публичной сети, ни его цепочка. Ветка продления не проверялась вовсе — тест каждый раз вынуждает новую проверку. Только HTTP-01, без wildcard-сертификатов: они придут вместе с управлением DNS.
• Удаление базы данных окончательно. Нет ни снимка, ни корзины, ни задержки, и путь удаления никак не обращается к модулю резервных копий. База восстановима только из копии, которая уже существовала.
• Конфигурация SSH-демона отслеживается, и у слежения названа граница. Установщик пишет блок, который делает вход для передачи файлов запертым, а мониторинг теперь читает этот блок обратно и поднимает тревогу при расхождении — причём все четыре директивы по отдельности, поэтому блок с уцелевшим заголовком и опустошённым телом тоже будет пойман. Читается файл конфигурации, а не ответ демона: sshd -T вообще никогда не печатает содержимое блока Match. Чего слежение не делает: не идёт по директивам Include и не доказывает, что на разошедшемся хосте действительно выдаётся шелл. Оно сообщает, что конфигурация больше не говорит написанного.

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

Обновление с 0.1.0

Пути обновления нет, и он не нужен: 0.1.0 был каркасом без хостинговых функций, и сохранять на нём было нечего.