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

Пароль нужен только чтобы открыть первое 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-подписью.

Секреты ключей Partner API необратимы: полный ключ показывается только один раз при выпуске, а в базе остаётся SHA-256 его секретной части. Access- и refresh-токены подключённых ИИ также не хранятся открытым текстом; подключение ограничено выбранным уровнем доступа и может быть отозвано владельцем аккаунта.

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

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

В маршрутах панели partner_id выводится из подписанной сессии, в Partner API — из проверенного API-ключа или OAuth-подключения ИИ. Идентификатор владельца не берётся из пути, query-параметров или тела запроса. API-ключи дополнительно ограничены scope, сроком действия и тарифом; у подключённого ИИ набор прав вычисляется из выбранного владельцем уровня при каждом запросе.

Прежде чем что-либо отдать или изменить, система перепроверяет, что сервер, кластер, инбаунд, маршрут, VPN-пользователь или платёж принадлежит этому аккаунту. Запросы к базе ограничены partner_id, а составные уникальные и внешние ключи отклоняют некорректные межпартнёрские связи. Матрица авторизации в тестах требует явного IDOR-сценария для каждой ручки с идентификатором ресурса.

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

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

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

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

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

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

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

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

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

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

Оплата и все карточные данные обрабатываются на стороне подключённого провайдера (lava.top). К нам приходит только проверенное событие webhook: его подлинность устанавливается способом, который поддерживает конкретный провайдер, до изменения баланса или доступа. Полного номера карты (PAN) и CVV мы не получаем. Повторная доставка того же события не приводит к двойной выдаче: события дедуплицируются.

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

Для аккаунта хранятся email, время последнего входа, режим интерфейса и настройки; для биллинга — баланс и Telegram, если он указан для пополнений. Для защиты аккаунта активная сессия содержит время создания и последней активности, IP-адрес и user-agent. История успешных и неудачных попыток входа с теми же техническими признаками хранится 90 дней.

Общей истории кликов по панели нет. Отдельно существуют целевые журналы: запросы Partner API — не более 500 последних записей и примерно 25 часов, события инфраструктуры и результаты диагностики — не более 7 дней, действия подключённых ИИ — вместе с аккаунтом. Перед записью действий ИИ пароли, токены, ключи и ссылки подписки удаляются, а email пользователей маскируются.

Фаервол по умолчанию запрещает входящие. Наружу открыты: 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 управляемых компонентов, например к сгенерированному админ-паролю сервера. Коды генерируются криптографическим генератором; хранится только их HMAC-хеш, а сравнение выполняется за постоянное время. Код при успехе сразу удаляется, а после 5 неверных попыток гасится досрочно. Ограничение частоты выдачи считается и по полному адресу, и по физическому почтовому ящику: смена IP, точки в Gmail и plus-теги не дают отдельный лимит.

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

Каждая партнёрская сессия имеет стабильный серверный идентификатор, который сохраняется при продлении токена. Обычный выход отзывает всю текущую сессию, а не только один выпуск токена. В разделе «Сессии аккаунта» видны устройство, IP-адрес, время входа и последняя активность; любую сессию можно завершить отдельно. Действие «Выйти на всех устройствах» завершает все сессии и отключает подключённых ИИ.

История входов хранится 90 дней и показывает успешные входы, неверные и истёкшие коды, а также превышение числа попыток. При признаках повторного использования уже обменянного выпуска система считает сессию скопированной, завершает все сессии и подключения ИИ и отправляет владельцу уведомление.

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

Есть намеренные исключения, которыми управляет сам владелец: экспорт приватного SSH-ключа после кода из письма (SR-4) и новый ключ Partner API, полный секрет которого показывается в браузере один раз при создании. После этого восстановить его из базы нельзя — там остаётся только хеш. Публичный API-домен доступен из интернета по назначению, но без действующей сессии, API-ключа или OAuth-токена защищённых данных не отдаёт.

Публичные хосты CreateYourVPN отдаются по HTTPS с HSTS (max-age два года, includeSubDomains). Каждый веб-фронтенд, который мы размещаем, — сайт платформы, партнёрская панель и витрины партнёров, будь то на наших поддоменах или на собственном домене партнёра, — а также API-домен присылают один и тот же набор security-заголовков: Content-Security-Policy (default-src 'none' на API; на фронтендах он запрещает встраивание в iframe и фиксирует base-uri и form-action), X-Content-Type-Options: nosniff, X-Frame-Options и жёсткий Referrer-Policy (no-referrer на API; strict-origin-when-cross-origin на фронтендах, которые также отдают ограничительный Permissions-Policy).

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

ИИ-приложение подключается через OAuth и не получает cookie вашей панели. На странице согласия вы выбираете один из трёх уровней: только просмотр; просмотр и настройка; удаление и выдача доступа. Права проверяются сервером при каждом вызове. Критичные удаления требуют дополнительного одноразового кода из письма, а всё подключение можно отозвать в разделе «Подключённые ИИ».

Каждый вызов инструмента попадает в видимый владельцу журнал с результатом и безопасной копией аргументов. Пароли, токены, API-ключи, приватные ключи и ссылки подписки вырезаются до записи; email пользователей маскируются. При этом выбранное ИИ-приложение остаётся сторонним сервисом: данные, которые вы сознательно поручили ему прочитать или изменить, обрабатываются также по правилам его поставщика.