Перевірювані твердження.

Пароль потрібен лише щоб відкрити перше 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 користувачів маскується. Водночас вибраний ШІ-застосунок залишається стороннім сервісом: дані, які ви свідомо доручили йому прочитати чи змінити, обробляються також за правилами його постачальника.