Проверяемые утверждения.

Пароль нужен только чтобы открыть первое SSH-соединение и поставить служебного пользователя. Он передаётся как SSH-аутентификация нашего подключения — не как аргумент или переменная скрипта. В нашей базе для него нет поля; он не попадает в env прогонов скриптов и не пишется в логи (ошибки подключения содержат только адрес и порт, но не пароль). В оперативной памяти он затирается (best-effort) после использования — это защита в глубину, а не гарантия: Go может держать копии значения в куче до сборки мусора.

Честная оговорка: это остаётся паролем root на вашем сервере. После установки мы отключаем вход по паролю и под root по SSH, но сам пароль не меняем — при желании смените его сами. «Мы не храним» — правда; «он перестал быть секретом» — нет.

PasswordAuthentication no, PermitRootLogin no, SSH перенесён на нестандартный порт (по умолчанию 12011), включён fail2ban (бан на час после 5 неудач), вход — только по ключу. Публичный ключ строго валидируется до применения: отвергаются переносы строк (защита от подмешивания лишних ключей в authorized_keys) и синтаксически некорректные ключи.

Анти-локаут: порт 22 не закрывается, пока ядро не подтвердит (через ss), что новый SSH-порт действительно слушает; конфиг проверяется через sshd -t, правило sudo — через visudo -cf, оба откатываются при ошибке.

Панель работает не вашим паролем, а отдельным ключом (ed25519), который она генерирует сама. Приватная часть лежит в базе зашифрованной AES-256-GCM. Ключ шифрования (KEK) хранится отдельно от базы — в переменной окружения сервера — и в проде он обязателен (небезопасного дефолта нет: без KEK крипто-подсистема просто не запускается). Тем же шифрованием защищены тяжёлые секреты в базе — админ-пароль/токен/JWT Marzban, Reality-ключи, ключи payment-провайдеров, кэш proxy-кредов, конфиг бэкапов.

Шифрование не просто скрывает, а аутентифицирует данные (GCM auth-tag): подмена зашифрованного поля обнаруживается при расшифровке и отвергается. Каждое поле шифруется со свежим случайным nonce; значение KEK в логи не попадает — только его короткий id.

О capability-токенах: токен подписки /sub — это bearer-секрет. Для поиска мы храним только его SHA-256, а копию, необходимую для повторного показа уже выданной ссылки, держим в виде AES-GCM шифртекста. Старые plaintext-записи переводятся в новый формат fail-closed до запуска HTTP-сервера. Идентификатор URL платёжного webhook хранится открыто, но сам по себе не аутентифицирует событие: подлинность отдельно проверяется HMAC-подписью.

Ключ расшифровывается только на сервере, в оперативной памяти; обычные API его никогда не отдают. Единственный способ его получить — намеренная функция экспорта («забрать свой ключ»), защищённая входом плюс одноразовым кодом на email (код хранится только как HMAC-хеш, сверка постоянного времени, TTL 10 минут, 5 попыток). То есть ключ можно достать сознательно, но не «утечкой» через обычный запрос.

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

Проверенные партнёрские маршруты авторизуются по partner_id, который сервер выводит из подписанного токена входа — а не из того, что клиент прислал в пути или теле запроса. Прежде чем что-либо отдать или изменить, система перепроверяет, что запрошенный сервер, кластер, инбаунд, маршрут, VPN-пользователь или платёж принадлежит вашему аккаунту; соответствующие запросы к базе ограничены вашим partner_id, а схема (составные уникальные ключи плюс составные внешние ключи) отклоняет некорректные межпартнёрские связи. Изоляция эшелонированная: приложение, перепроверка в usecase, фильтр по partner_id и схема.

Честная оговорка: это проверено аудитом кода по всему пути запроса, а не публичным пентестом — поэтому SR-16, как и остальные, открыт для опровержения в bug bounty.

Чтобы всё настраивать автоматически (устанавливать Xray+Reality, применять конфиг, читать метрики), панель держит на сервере полный административный доступ (эквивалент root, через служебного пользователя с sudo без пароля). Это необходимо для управления, и мы НЕ называем его «ограниченным».

Что снижает риск: секреты передаются на сервер только через stdin процесса (не как аргументы команды — их не видно в списке процессов); после первичной установки каждое управляющее подключение проверяет закреплённый host-key сервера — подмена сервера «на пути» отбивается. Что вы контролируете: доступ держится на ключе, который вы в любой момент можете отозвать — удалив сервер (ключ обнуляется) или просто удалив VPS у хостера (тогда исчезает вообще всё).

Сами VPN-аккаунты (VLESS/Reality) создаются и живут в Marzban на вашем master-сервере. Централизованно мы храним только то, без чего нельзя выдать ссылку-подписку: случайный токен подписки и зашифрованный слепок proxy-кредов (кэш; источник истины — ваш Marzban). Ни трафика, ни IP, ни истории посещений пользователей у нас нет.

Честно перечислим случаи, где email конечного пользователя всё же проходит через нашу центральную базу: письмо с кодом входа отправляем мы, поэтому адрес проходит через очередь отправки (для любого входа в витрину, включая бесплатный); при оплате email покупателя приходит в платёжном webhook и попадает в журнал платежей; при привязке Telegram email сохраняется в профиле. Это единственные касания — служебные и по необходимости; трафика и поведения пользователей они не затрагивают.

Эти служебные данные мы храним ровно столько, сколько нужно, и очищаем автоматически: email — из очереди сразу после отправки, тело платёжного события — после обработки, а события на ретрае — до окна в 90 дней. Удалить аккаунт вместе со связанными данными можно, написав в поддержку (подробнее — риск 7). Мы раскрываем это честно, а не прячем за общими словами.

Платформа CreateYourVPN не получает и не хранит информацию о том, какие сайты посещаете вы или ваши пользователи. Схема приёма метрик закрыта: в ней физически нет полей под IP, домены или посещения — только агрегаты (число уникальных онлайн, суммарные байты, CPU/RAM/нагрузка). Каждая нода аутентифицируется HMAC-токеном, привязанным к её собственному id, и может писать метрики только за себя. Балансировщик на ноде (HAProxy) работает как TCP-роутер по SNI и не расшифровывает трафик. На самом сервере системные журналы удерживаются не дольше примерно часа и не форвардятся в syslog.

Кроме уровня платформы, и сами серверы не ведут журнал посещений: журнал доступа Xray принудительно отключён на каждом пуше конфига (платформа выставляет log.access в none), поэтому пограничный прокси не записывает, к каким адресам подключаются пользователи. Это зафиксировано в коде и раскатано на флот.

Чтобы понимать, как используют сайт и панель, мы применяем Google Analytics (о сборе cookie и статистики предупреждает куки-баннер, детали — в Политике конфиденциальности). Других сторонних трекеров нет: ни Sentry, ни PostHog, ни Mixpanel, ни рекламных пикселей (проверено поиском по обоим фронтендам). В бэкенде сторонней телеметрии нет вовсе. Витрина для конечных пользователей аналитикой не покрыта вообще — ни GA, ни трекеров (проверяемо по её исходникам).

Оговорка: GA получает ваш IP (на стороне Google) и адреса просматриваемых страниц панели; в URL панели — только идентификатор кластера, не email.

Оплата и все карточные данные обрабатываются на стороне провайдера (Tribute / Lemon Squeezy). К нам приходит только подписанный webhook (HMAC-SHA256, сверка постоянного времени, проверяется до разбора тела и до любой записи в базу: без знания секрета событие не проходит проверку). Полного номера карты (PAN) и CVV мы не получаем. Повторная доставка того же webhook (ретраи провайдера) не приводит к двойной выдаче — события дедуплицируются.

Оговорка: провайдер может включать в тело webhook метаданные карты (бренд и последние 4 цифры) и имя и email плательщика. Исходное тело требуется воркеру до завершения обработки; после успешной обработки оно удаляется вместе с email-подсказкой. События, ожидающие ретрая или ручного разбора, сохраняют исходное тело только до конца окна хранения (90 дней без активности), после чего метаданные карты и email плательщика автоматически удаляются. «Полного номера карты нет» — правда, но это свойство провайдеров (само тело мы не фильтруем); «мы вообще ничего не видим про карту» — нет.

Email (нужен для входа), время последнего входа, режим интерфейса; для биллинга — баланс и Telegram (для пополнений). IP партнёра в базе не хранится, историю кликов или действий в панели мы не ведём (кроме короткого access-лога при ошибках).

Фаервол по умолчанию запрещает входящие. Наружу открыты: 443 (VPN, Xray+Reality), SSH на нестандартном порту (по умолчанию 12011) и — на master-сервере — порт админ-панели Marzban, только для IP control-plane. Порт 80 открывается отдельно только в режиме Let's Encrypt для HTTP-01. Порт 22 закрывается после переноса SSH.

Управляющие порты ноды открыты только для IP master-сервера, а не наружу (провал этой привязки прерывает установку). Если фаервол не становится активным, установка завершается ошибкой. ICMP echo ограничивается только для IPv4; мы не обещаем, что сервер «невидим», а IPv6 ICMP сохраняется, чтобы IPv6 работал корректно.

Unattended upgrades устанавливает обновления безопасности пакетов автоматически. Оговорка: авто-перезагрузка намеренно выключена (чтобы непроверенное ядро не ушло в ребут само) — значит фиксы, требующие перезагрузки (ядро, иногда OpenSSH), применяются только после ручного или планового ребута. «Автопатчинг» — правда для userland, но не для того, что требует ребута.

Мы НЕ утверждаем, что сервер «невидим» или «его нельзя просканировать». Порт 443 открыт и отвечает на TCP-соединение, как любой веб-сервер. Свойство «на некорректное подключение выглядит как обычный чужой сайт» обеспечивает протокол Reality внутри Xray — это отдельный компонент, и в абсолют мы его не возводим.

Вход партнёра — по одноразовому 6-значному коду на email. Пароля аккаунта нет. Это не относится к внутренним credentials управляемых компонентов, например к сгенерированному админ-паролю Marzban. Коды генерируются криптографическим генератором; хранится только их HMAC-хеш, а сравнение — постоянного времени. Код одноразовый: при успехе сразу удаляется (повтор невозможен); после 5 неверных попыток гасится досрочно. Ограничение частоты выдачи считается по email, а не по IP — его нельзя обойти сменой адреса.

Токен сессии лежит в cookie HttpOnly и Secure (JS его не прочитает), проверяется на бэкенде (не только на краю). Таймаут простоя и авто-выход по бездействию реализованы на клиенте, не на сервере. Токен подписан HS256; при проверке мы жёстко отклоняем любой другой алгоритм (включая «none») — классическая атака подмены алгоритма не проходит. Токен витрины и токен партнёрской панели разделены по audience: токен конечного пользователя технически не может обращаться к партнёрскому API (и наоборот). Удалённый партнёр отбивается даже с живым токеном.

Оговорка: отзыв реализован проверкой существования партнёра на каждом запросе, а не инвалидацией самого токена; выход удаляет cookie, но выпущенный токен остаётся криптографически валидным до истечения (до часа). Централизованного revocation-list пока нет (осознанное упрощение MVP).

В локальном хранилище браузера токенов нет (только UI-настройки); секреты и адрес API в клиентский бандл не попадают. Токен в HttpOnly-cookie кладёт только сервер (Next.js). Браузер общается с ядром только через сервер (Server Actions): фронтенд не ходит в API напрямую из браузера, а CORS не разрешает браузерное чтение ответов API с других origin.

Уточнение вместо прежнего абсолюта: сам API-домен — публичный хост, открыть его из браузера технически можно, но без сессии авторизованных данных он не отдаёт.

Публичные домены CreateYourVPN отдаются по HTTPS с HSTS (max-age два года, includeSubDomains). И веб-фронт, и API-домен присылают строгий набор security-заголовков: ограничительный Content-Security-Policy, X-Content-Type-Options: nosniff, X-Frame-Options и жёсткий Referrer-Policy (no-referrer на API; strict-origin-when-cross-origin на фронте, который также отдаёт заблокированный Permissions-Policy).

Это работает в проде на обоих доменах и проверяется независимо — любым инспектором HTTP-заголовков или сервисом вроде SSL Labs.