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.

Secretele cheilor Partner API sunt stocate ireversibil: cheia completă este afișată o singură dată, la emitere, iar în baza de date rămâne SHA-256-ul părții sale secrete. Nici tokenurile access și refresh ale serviciilor de IA conectate nu sunt stocate în text clar; conexiunea este limitată la nivelul de acces ales și poate fi revocată de proprietarul contului.

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.

În rutele panoului, partner_id este derivat din sesiunea semnată, iar în Partner API — dintr-o cheie API verificată sau dintr-o conexiune OAuth a unei IA. Identificatorul proprietarului nu este preluat din path, din parametrii query sau din body-ul cererii. Cheile API sunt limitate suplimentar prin scope, termen de valabilitate și plan; pentru o IA conectată, setul de permisiuni este calculat la fiecare cerere pe baza nivelului ales de proprietar.

Înainte de a returna sau modifica ceva, sistemul reverifică faptul că serverul, clusterul, inboundul, ruta, utilizatorul VPN sau plata aparțin acestui cont. Interogările către baza de date sunt limitate de partner_id, iar cheile unice și externe compuse resping legăturile încrucișate invalide între parteneri. Matricea de autorizare din teste cere un scenariu IDOR explicit pentru fiecare endpoint cu identificator de resursă.

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.

Adresa de e-mail a unui utilizator final nu este stocată la noi: numele contului său este derivat ireversibil și nu conține nicio adresă. E-mailul cu codul de autentificare îl trimitem noi, așa că adresa trece prin coada noastră de trimitere și este eliminată din ea imediat după expediere — pentru a recunoaște un utilizator care revine rămâne doar o amprentă ireversibilă, din care adresa nu poate fi recuperată. Singurul caz în care o adresă rămâne totuși îl numim direct: la plată ajunge în webhookul de plată și intră în jurnalul plăților cu o durată de păstrare limitată.

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 singur contul împreună cu toate datele lui, în secțiunea „Setări avansate”, confirmând cu un cod primit pe e-mail (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). Pe paginile de consimțământ OAuth, analitica nu se încarcă în niciun caz: URL-ul conține un identificator de scurtă durată al cererii de conectare a unei IA, care nu trebuie transmis unor terți. Nu există alte trackere terțe: niciun Sentry, PostHog, Mixpanel sau pixel publicitar. Backendul nu are telemetrie terță, iar vitrinele utilizatorilor finali nu sunt acoperite de analitică.

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 conectat (lava.top). Primim doar un eveniment webhook verificat: autenticitatea lui este stabilită prin metoda pe care o acceptă furnizorul respectiv, înainte de orice modificare a soldului sau a accesului. Nu primim numărul complet al cardului (PAN) sau CVV. Relivrarea aceluiași eveniment 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.

Pentru cont sunt stocate adresa de email, ora ultimei autentificări, modul interfeței și setările; pentru facturare — soldul și Telegram, dacă este indicat pentru reîncărcări. Pentru protecția contului, o sesiune activă conține ora creării și a ultimei activități, adresa IP și user-agentul. Istoricul încercărilor de autentificare reușite și eșuate, cu aceleași atribute tehnice, este păstrat 90 de zile.

Nu există un istoric general al click-urilor în panou. Separat există jurnale dedicate: cererile către Partner API — cel mult ultimele 500 de înregistrări și aproximativ 25 de ore; evenimentele de infrastructură și rezultatele diagnosticării — cel mult 7 zile; acțiunile serviciilor de IA conectate — pe toată durata existenței contului. Înainte de înregistrarea acțiunilor IA, parolele, tokenurile, cheile și linkurile de abonament sunt eliminate, iar adresele de email ale utilizatorilor sunt mascate.

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 generată pentru server. Codurile sunt generate de un generator criptografic; se stochează doar hash-ul lor HMAC, iar comparația se face în timp constant. La succes, codul este șters imediat, iar după 5 încercări greșite este dezactivat din timp. Limita de frecvență a emiterii este numărată atât pe adresa completă, cât și pe căsuța poștală fizică: schimbarea IP-ului, punctele din adresele Gmail și plus-tagurile nu oferă o limită separată.

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.

Fiecare sesiune de partener are un identificator stabil pe server, care se păstrează la reînnoirea tokenului. Deconectarea obișnuită revocă întreaga sesiune curentă, nu doar o singură emitere a tokenului. În secțiunea „Sesiunile contului” sunt vizibile dispozitivul, adresa IP, ora autentificării și ultima activitate; orice sesiune poate fi încheiată separat. Acțiunea „Deconectare peste tot” încheie toate sesiunile și deconectează serviciile de IA conectate.

Istoricul autentificărilor este păstrat 90 de zile și arată autentificările reușite, codurile greșite și expirate, precum și depășirea numărului de încercări. La semne de reutilizare a unei emiteri a tokenului deja schimbate, sistemul consideră sesiunea copiată, încheie toate sesiunile și conexiunile IA și trimite o notificare proprietarului.

În local storage-ul browserului nu există tokenuri de sesiune, doar setări de interfață. Tokenul din cookie-ul HttpOnly este plasat de stratul de server Next.js; browserul nu primește adresa internă a backendului și ajunge la el prin Server Actions. CORS nu permite altor origini să citească răspunsurile API cu date autorizate.

Există excepții intenționate, controlate chiar de proprietar: exportul cheii SSH private după codul primit pe email (SR-4) și o cheie nouă Partner API, al cărei secret complet este afișat în browser o singură dată, la creare. După aceea nu mai poate fi recuperat din baza de date — acolo rămâne doar hash-ul. Domeniul public al API-ului este accesibil din internet în mod intenționat, dar fără o sesiune validă, o cheie API sau un token OAuth nu returnează date protejate.

Hosturile publice CreateYourVPN sunt servite prin HTTPS cu HSTS (max-age doi ani, includeSubDomains). Fiecare frontend web pe care îl găzduim — site-ul platformei, panoul partenerilor și magazinele partenerilor, fie pe subdomeniile noastre, fie pe domeniul propriu al partenerului — și domeniul API trimit același set de anteturi de securitate: o Content-Security-Policy (default-src 'none' pe API; pe frontenduri interzice încorporarea într-un iframe și fixează base-uri și form-action), X-Content-Type-Options: nosniff, X-Frame-Options și o Referrer-Policy strictă (no-referrer pe API; strict-origin-when-cross-origin pe frontenduri, care trimit și o Permissions-Policy restrictivă).

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

Aplicația de IA se conectează prin OAuth și nu primește cookie-urile panoului tău. Pe pagina de consimțământ alegi unul dintre cele trei niveluri: doar vizualizare; vizualizare și configurare; ștergere și acordare de acces. Permisiunile sunt verificate de server la fiecare apel. Ștergerile critice necesită un cod suplimentar de unică folosință primit pe email, iar întreaga conexiune poate fi revocată în secțiunea „IA conectate”.

Fiecare apel de instrument ajunge într-un jurnal vizibil pentru proprietar, cu rezultatul și o copie sigură a argumentelor. Parolele, tokenurile, cheile API, cheile private și linkurile de abonament sunt eliminate înainte de înregistrare; adresele de email ale utilizatorilor sunt mascate. Totuși, aplicația de IA aleasă rămâne un serviciu terț: datele pe care, în mod conștient, i-ai cerut să le citească sau să le modifice sunt prelucrate și conform regulilor furnizorului său.