Afirmații verificabile.

Parola este necesară doar pentru a deschide prima conexiune SSH și a instala un utilizator de serviciu. Este transmisă ca autentificare SSH pentru conexiunea noastră — nu ca argument de script sau variabilă de mediu. Baza noastră de date nu are un câmp pentru ea; nu intră în mediile de execuție a scripturilor și nu este scrisă în jurnale (erorile de conexiune conțin doar adresa și portul, niciodată parola). În memorie este ștearsă (best-effort) după utilizare — aceasta este apărare în adâncime, nu o garanție: Go poate păstra copii ale valorii în heap până la garbage collection.

Rezervă onestă: aceasta rămâne parola de root de pe serverul tău. După instalare dezactivăm autentificarea SSH cu parolă și ca root, dar nu schimbăm parola în sine — schimbă-o tu dacă vrei. „Nu o stocăm” este adevărat; „a încetat să mai fie un secret” nu.

PasswordAuthentication no, PermitRootLogin no, SSH mutat pe un port non-standard (12011 în mod implicit), fail2ban activat (un ban de o oră după 5 eșecuri), autentificare doar cu cheie. Cheia publică este validată riguros înainte de utilizare: sunt respinse rândurile noi (protecție împotriva strecurării de chei suplimentare în authorized_keys) și cheile invalide sintactic.

Anti-lockout: portul 22 nu este închis până când kernelul nu confirmă (prin ss) că noul port SSH ascultă efectiv; configurația este verificată cu sshd -t, iar regula sudo cu visudo -cf, ambele anulate în caz de eroare.

Panoul nu lucrează cu parola ta, ci cu o cheie separată (ed25519) pe care o generează el însuși. Partea privată se află în baza de date criptată cu AES-256-GCM. Cheia de criptare (KEK) este stocată separat de baza de date — într-o variabilă de mediu a serverului — iar în producție este obligatorie (nu există o valoare implicită nesigură: fără o KEK, subsistemul criptografic pur și simplu nu pornește). Aceeași criptare protejează secretele grele din baza de date — parola/tokenul/JWT-ul de administrator Marzban, cheile Reality, cheile furnizorilor de plăți, cache-ul de credențiale proxy, configurația backupurilor.

Criptarea nu doar ascunde, ci autentifică datele (auth tag GCM): modificarea unui câmp criptat este detectată la decriptare și respinsă. Fiecare câmp este criptat cu un nonce aleatoriu nou; valoarea KEK nu ajunge niciodată în jurnale — doar id-ul ei scurt.

Despre tokenurile de acces: tokenul de abonare /sub este un secret la purtător. Pentru căutare stocăm doar SHA-256-ul său, în timp ce copia necesară pentru a reafișa un link deja emis este păstrată ca text cifrat AES-GCM. Înregistrările mai vechi în text clar sunt migrate în noul format, în mod fail-closed, înainte ca serverul HTTP să pornească. Identificatorul URL al webhookului de plată este stocat în clar, dar nu autentifică prin el însuși un eveniment: autenticitatea este verificată separat printr-o semnătură HMAC.

Cheia este decriptată doar pe server, în memorie; API-urile obișnuite nu o returnează niciodată. Singura modalitate de a o obține este o funcție de export deliberată („ia-ți cheia”), protejată prin autentificare plus un cod de email de unică folosință (codul este stocat doar ca hash HMAC, comparat în timp constant, TTL de 10 minute, 5 încercări). Așadar cheia poate fi obținută intenționat, dar nu poate „scăpa” printr-o cerere normală.

Înainte ca starea serverului să se schimbe și înainte de orice operațiune de rețea în fundal, câmpurile care conțin cheia de gestionare sunt aduse la zero sincron. Dacă baza de date nu confirmă ștergerea, operațiunea returnează o eroare și poate fi reîncercată. Ștergerea rămâne „soft”: rândul și datele de serviciu nesecrete sunt păstrate. Aceasta nu înseamnă ștergerea fizică a backupurilor deja create — ciclul lor de viață este reglementat de politica de retenție a backupurilor.

Rutele de partener auditate autorizează pe baza partner_id, pe care serverul îl derivă din tokenul de login semnat — nu din ceea ce a trimis clientul în path sau body. Înainte de a returna sau modifica ceva, sistemul reverifică faptul că serverul, clusterul, inboundul, ruta, utilizatorul VPN sau plata solicitate aparțin contului tău; interogările corespunzătoare către baza de date sunt limitate de partner_id-ul tău, iar schema (chei unice compuse plus chei externe compuse) respinge legăturile încrucișate invalide între parteneri. Izolarea este pe mai multe niveluri: aplicație, reverificare în usecase, un filtru partner_id și schema.

Rezervă onestă: acest lucru este verificat printr-un audit de cod de-a lungul întregului traseu al cererii, nu printr-un test de penetrare public — așadar SR-16, ca și restul, este deschis contestării în bug bounty.

Pentru a configura totul automat (a instala Xray+Reality, a aplica configurația, a citi metricile) panoul deține acces administrativ complet pe server (echivalent root, printr-un utilizator de serviciu cu sudo fără parolă). Este necesar pentru gestionare și NU îl numim „limitat”.

Ce reduce riscul: secretele sunt transmise serverului doar prin stdin-ul procesului (nu ca argumente de comandă — nu sunt vizibile în lista de procese); după instalarea inițială, fiecare conexiune de gestionare verifică host key-ul fixat (pinned) al serverului — o înlocuire a serverului „la mijloc” este respinsă. Ce controlezi tu: accesul se bazează pe o cheie pe care o poți revoca oricând — ștergând serverul (cheia este adusă la zero) sau pur și simplu ștergând VPS-ul la furnizorul tău (atunci totul dispare).

Conturile VPN în sine (VLESS/Reality) sunt create și se află în Marzban pe serverul tău master. Central stocăm doar ceea ce este necesar pentru a emite un link de abonare: un token de abonare aleatoriu și un snapshot criptat al credențialelor proxy (un cache; sursa de adevăr este Marzbanul tău). Nu avem niciun istoric de trafic, IP sau vizite ale utilizatorilor.

Iată o listă onestă a locurilor prin care e-mailul unui utilizator final chiar trece prin baza noastră de date centrală: e-mailul cu codul de conectare este trimis de noi, așa că adresa trece prin coada noastră de trimitere (pentru orice conectare la magazin, inclusiv cea gratuită); la plată, e-mailul cumpărătorului ajunge în webhookul de plată și intră în jurnalul de plăți; la conectarea Telegram, e-mailul este salvat în profil. Acestea sunt singurele puncte de contact — de serviciu și din necesitate; niciunul dintre ele nu implică trafic sau comportamentul utilizatorilor.

Aceste date de serviciu le păstrăm doar cât este necesar și le ștergem automat: e-mailul este eliminat din coada de trimitere imediat după trimitere, conținutul unui eveniment de plată după procesare, iar evenimentele care așteaptă o reîncercare într-o fereastră de 90 de zile. Îți poți șterge contul împreună cu datele asociate contactând asistența (vezi riscul 7 pentru detalii). Dezvăluim acest lucru în mod deschis, în loc să îl ascundem în spatele unor formulări vagi.

Platforma CreateYourVPN nu primește și nu stochează informații despre ce site-uri vizitezi tu sau utilizatorii tăi. Schema de ingerare a metricilor este închisă: fizic nu are câmpuri pentru IP-uri, domenii sau vizite — doar agregate (număr de unici online, total octeți, CPU/RAM/încărcare). Fiecare nod se autentifică cu un token HMAC legat de propriul id și poate scrie metrici doar pentru sine. Balancerul de pe nod (HAProxy) funcționează ca router TCP după SNI și nu decriptează traficul. Pe serverul propriu-zis, jurnalele de sistem sunt păstrate cel mult aproximativ o oră și nu sunt transmise către syslog.

Dincolo de nivelul platformei, nici serverele nu păstrează un jurnal al vizitelor: jurnalizarea accesului Xray este dezactivată forțat la fiecare împingere de configurație (platforma setează log.access la none), astfel încât proxy-ul de margine nu înregistrează la ce adrese se conectează utilizatorii. Acest lucru este impus în cod și implementat pe întreaga flotă.

Pentru a înțelege cum sunt folosite site-ul și panoul folosim Google Analytics (bannerul de cookie-uri avertizează despre colectarea de cookie-uri și statistici; detaliile sunt în Politica de confidențialitate). Nu există alte trackere terțe: niciun Sentry, PostHog, Mixpanel sau pixel publicitar (verificat prin căutarea în ambele frontenduri). Backendul nu are deloc telemetrie terță. Vitrina pentru utilizatorul final nu este acoperită deloc de analitică — niciun GA, niciun tracker (verificabil din sursele sale).

Rezervă: GA primește IP-ul tău (de partea Google) și adresele paginilor de panou vizualizate; URL-urile panoului conțin doar un identificator de cluster, nu un email.

Plata și toate datele cardului sunt gestionate de partea furnizorului (Tribute / Lemon Squeezy). Primim doar un webhook semnat (HMAC-SHA256, comparație în timp constant, verificat înainte ca body-ul să fie parsat și înainte de orice scriere în baza de date: fără a cunoaște secretul, un eveniment nu trece verificarea). Nu primim numărul complet al cardului (PAN) sau CVV. Relivrarea aceluiași webhook (reîncercările furnizorului) nu provoacă o dublă acordare — evenimentele sunt deduplicate.

Rezervă: furnizorul poate include în body-ul webhookului metadate ale cardului (rețeaua și ultimele 4 cifre) și numele și emailul plătitorului. Body-ul original este necesar workerului până la finalizarea procesării; după o procesare reușită este șters împreună cu indiciul emailului. Evenimentele care așteaptă o reîncercare sau o revizuire manuală păstrează body-ul original doar până la sfârșitul ferestrei de retenție (90 de zile fără activitate), după care metadatele cardului și emailul plătitorului sunt șterse automat. „Nu există numărul complet al cardului” este adevărat, dar aceasta este o proprietate a furnizorilor (nu filtrăm noi înșine body-ul); „nu vedem absolut nimic despre card” nu.

Email (necesar pentru autentificare), ora ultimei autentificări, modul interfeței; pentru facturare — soldul și Telegram (pentru reîncărcări). IP-ul partenerului nu este stocat în baza de date, iar noi nu păstrăm niciun istoric de click-uri sau acțiuni în panou (în afară de un scurt jurnal de acces în caz de erori).

Firewallul refuză traficul de intrare în mod implicit. Deschise către exterior: 443 (VPN, Xray+Reality), SSH pe un port non-standard (12011 în mod implicit) și — pe serverul master — portul panoului de administrare Marzban, doar pentru IP-urile din control-plane. Portul 80 este deschis separat doar în modul Let's Encrypt pentru HTTP-01. Portul 22 este închis după ce SSH este mutat.

Porturile de gestionare ale nodului sunt deschise doar către IP-ul serverului master, nu către exterior (un eșec al acestei legări întrerupe instalarea). Dacă firewallul nu devine activ, instalarea eșuează. Echo-ul ICMP este limitat doar pentru IPv4; nu promitem că serverul este „invizibil”, iar ICMP-ul IPv6 este păstrat pentru ca IPv6 să funcționeze corect.

Unattended upgrades instalează automat actualizările pachetelor de securitate. Rezervă: repornirea automată este dezactivată în mod deliberat (astfel încât un kernel neverificat să nu se repornească singur) — ceea ce înseamnă că remedierile care necesită o repornire (kernel, uneori OpenSSH) se aplică doar după o repornire manuală sau programată. „Auto-patching” este adevărat pentru userland, nu pentru ceea ce necesită o repornire.

NU pretindem că serverul este „invizibil” sau „nu poate fi scanat”. Portul 443 este deschis și răspunde la o conexiune TCP ca orice server web. Proprietatea „la o conexiune incorectă arată ca un site web obișnuit fără legătură” este oferită de protocolul Reality din interiorul Xray — o componentă separată pe care nu o transformăm într-un absolut.

Autentificarea partenerului se face printr-un cod de unică folosință de 6 cifre trimis pe email. Nu există o parolă de cont. Aceasta nu se aplică credențialelor interne ale componentelor gestionate, precum parola de administrator Marzban generată. Codurile sunt generate de un generator criptografic; se stochează doar hash-ul lor HMAC, iar comparația se face în timp constant. Codul este de unică folosință: la succes este șters imediat (fără replay); după 5 încercări greșite este dezactivat din timp. Limita de frecvență a emiterii este numărată pe email, nu pe IP — nu poate fi ocolită schimbând adresele.

Tokenul de sesiune se află într-un cookie HttpOnly și Secure (JS nu îl poate citi), verificat pe backend (nu doar la edge). Idle timeout-ul și delogarea automată la inactivitate sunt implementate pe client, nu pe server. Tokenul este semnat cu HS256; la verificare respingem riguros orice alt algoritm (inclusiv „none”) — clasicul atac de schimbare a algoritmului nu trece. Tokenul vitrinei și tokenul panoului de partener sunt separate prin audience: un token de utilizator final tehnic nu poate ajunge la API-ul de partener (și invers). Un partener șters este respins chiar și cu un token valid.

Rezervă: revocarea este implementată prin verificarea faptului că partenerul există la fiecare cerere, nu prin invalidarea tokenului în sine; delogarea șterge cookie-ul, dar un token emis rămâne valid criptografic până la expirare (până la o oră). Nu există încă o listă de revocare centralizată (o simplificare conștientă de MVP).

Nu există tokenuri în local storage-ul browserului (doar setări de interfață); niciun secret și nici adresa API nu ajung în bundle-ul de client. Doar serverul (Next.js) plasează tokenul într-un cookie HttpOnly. Browserul comunică cu nucleul doar prin server (Server Actions): frontendul nu apelează API-ul direct din browser, iar CORS nu permite browserului să citească răspunsurile API de la alte origini.

Clarificare în locul unui fost absolut: domeniul API este el însuși un host public — tehnic îl poți deschide dintr-un browser, dar fără o sesiune nu returnează niciun fel de date autorizate.

Domeniile publice CreateYourVPN sunt servite prin HTTPS cu HSTS (max-age doi ani, includeSubDomains). Atât frontendul web, cât și domeniul API trimit un set strict de anteturi de securitate: o Content-Security-Policy restrictivă, X-Content-Type-Options: nosniff, X-Frame-Options și o Referrer-Policy blindată (no-referrer pe API; strict-origin-when-cross-origin pe frontend, care trimite și o Permissions-Policy restrictivă).

Acest lucru rulează în producție pe ambele domenii și poate fi verificat independent — cu orice inspector de anteturi HTTP sau cu un serviciu precum SSL Labs.