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

Пароль потрібен лише щоб відкрити перше 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.